but why do my cpu is at 1600% load all the time?

i want

Why "was"?

Optimizely also sold to private equity many years ago. Presumably the founderts aren't there any more.

Eh? Did you really need to comment this?

Is LiveView same as Vaadin in Java world?

Not really, Vaadin is mainly a UI component lib and some convenience annotations, while LiveView is designed to allow soft-realtime UI views over WebSocket.

This is not a viable product, it's a feature

No static typing...

(Talking about CL) Isn't gradual typing with a typed standard library enough? Because that's kind of what SBCL provides.

Anyway, some other reasons:

* Baby ducks who can't get over the parentheses (which quickly become invisible to the eye, you read Lisp via its indentation).

* Baby ducks who can't get over too weird/big differences from C/C++/C#/Java/etc... like CL's compilation model.

* ML typing being /the/ fad these days.

* Low-level fetishism. I know a lot about this, since I've had my own C weenie phase (you know, the kind to spit on GC by principle) as a young university student, before turning smug lisp weenie ten years later; Tcl was actually my gateway drug into useful homoiconicity.

* Some hard technical limitations:

  * No user accessible parametric deftype.

  * No recursive deftype (so no typed lists/trees).

  * Gimped hash tables (untyped, lacking literals thus read/write transparency).

  * CLOS being bolted on instead of truly integrated in the language; would need a JIT and something like https://github.com/marcoheisig/fast-generic-functions on system classes to go fast enough, Julia kinda does this (but it hurts my eyes).

  * Lack of LSP; no, SLIME/Sly isn't the same, as you're lacking lexical information that allows to complete/rename stuff.

  * And hundreds of other rust spots sometimes fixed by extensions (e.g. gray streams, extensible sequences) or libraries (loop -> iterate, trivia), very often crutches in look and feel.

I've been meaning to give Coalton a try: https://coalton-lang.github.io/20211010-introducing-coalton/ (found via a previous HN post)

Optional static typing. Always strongly typed.

We tend to hope so, but CLHS is full of stuff like “the consequences are undefined if the value of the declared variable is not of the declared type” which gives a lot of leeway for generating code that blows up horribly.

I don't get it. How is this different than using standard Java ExecutorService & co features?

I'm curious as well. Once you can use an ExecutorService with virtual threads, the gap seems a bit thin.

The best I can tell is that coroutines are a bit lighter weight (in terms of what state is managed) and have a bit simpler usage out-of-the-box.

But I've not used them myself so maybe I'm not seeing how big of advantage those are or perhaps there's more to it than that?

Well for one, virtual threads would be implicit blocking and this style is explicit.

so kotlin functions are colored while java ones are colorless?

Java doesn't have an equivalent to Kotlin's 'suspend fun'. The CoroutineScope abstraction ('launch', 'join', 'await', etc) is also absent, at least until Structured Concurrency gets released [1] and Java gains StructuredTaskScope.

1: https://openjdk.org/jeps/462

It explicitly says it's not for actual use.

The point (I think) was as an exercise to demonstrate it was possible to implement in 'userland' and how they did so.

The runtime uses ExecutorService and friends to run coroutines, which are bits of CPS-transformed Kotlin code that are generated when you compile a 'suspend fun' declaration.

The way the code looks is completely different and significantly cleaner and faster to write in Kotlin. Actual performance and final functionality is likely to be same.