10 ms·

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 lib

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/concurrent/CompletionStage.html 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.

dahauns 9y ago
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...
- dmohs 9y ago
  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.