From my understanding, the article is about leveraging clojurescript serverside on nodejs. Then someone asks why just not write in clojure serverside on the jvm.

I just took some example languages, maybe I shouldn't have as it polluted my point with my own biases. It also felt relevant to bring them up, since it is what people mostly end up writing in, on those respective platforms. But I'm mostly interested in the JVM vs. node discussion though and opinions.

Yeah, the single threaded model + async can be nice and resolve problems with race conditions etc. making one headache go away. But it can also be a limiting factor that you cannot change if you need to, but then you maybe choose the wrong tech to begin with if your use case can include high cpu usage etc.

>Yeah, the single threaded model + async can be nice and resolve problems with race conditions etc. making one headache go away.

What often astounds me in these kinds of discussion: People just seem to assume that's not possible with the JVM.

So, just for the record (not neccesarily directed to you :) ): You can totally do node.js style (event-driven, async, nonblocking, no-shared-state - "single-threaded", if you will) with the jvm, and it works great (e.g. vertx, netty, play and many others).

And as you said: Contrary to node, with the JVM there's no danger of it being a limiting factor you're stuck with.

Nobody said it's not possible to do it on the JVM. It's also possible to do it in C.

It's totally different. There is no unified solution. Just about every library is blocking the thread and you have to code around that. And the solutions don't interop. And they can be atrocious abstractions: https://docs.oracle.com/javase/8/docs/api/java/util/concurre...

I work with Netty professionally and I would not call that a pleasant experience.

Async programming in Node has really good ergonomics that are hard to find elsewhere. For example, compare Promise.map(..., { concurrency: N }) to the Go solution.

Huh? Just about every library is blocking? Maybe x years ago. Get with the times.

And yeah, of course there's no single unified solution - the JVM landscape isn't restricted to a single programming model. That's actually its strength. Just because not every solution, every model works well together, doesn't mean that "the solutions don't interop" in general. (what are "the solutions"?)

And your general statement about "ergonomics that are hard to find elsewhere", yeah, that would really need a bit more than a small promise example to back it up...

Yes, you can often find async Java libraries to fit your architecture, but those are usually less mature than the thread-based ones. With Node libraries, your architecture is set, so you are free to pick the library that best meets your needs. This is a substantial benefit, which I say as someone who loves and regularly uses the ClojureScript on Node model and selected it only after running into this exact problem with Clojure on the JVM.