5 ms·

I think your view of history is a bit distorted. In my part of the JVM world (Scala) we've been async for well over a decade. The JVM has supported async / non-

I think your view of history is a bit distorted. In my part of the JVM world (Scala) we've been async for well over a decade. The JVM has supported async / non-blocking IO since nio circa 2003 (https://www.jcp.org/en/jsr/detail?id=51 https://www.jcp.org/en/jsr/detail?id=51). It was definitely not developed in response to Node or Go. Straightforward implementations of async are not very ergonomic to use without first class functions, which didn't come to Java till 2014 (Java 8), so that may have held back adoption for Java programmers. Graal Native Image is more about reducing startup time and memory usage (usually for serverless or command line applications) than async. As a final note, it's amusing that way before nio, Java actually had user-level / green threads but dropped them: https://en.wikipedia.org/wiki/Green_thread https://en.wikipedia.org/wiki/Green_thread

nvm0n2 3y ago
Yes but was NIO really usable for most tasks? Even with things like Netty to plumb it all the way to web server frameworks, databases and so on took a while. Like if you wanted to do SSL+async then a lot of manual work was required before Loom (if you want to use the stdlib). Native image isn't related to async for sure. I meant more that it's a feature that people like from Go, which has both AOT/static binaries and also usermode threads.
- noelwelsh 3y ago
  I can't really comment on the usability of nio as I've never directly used it. I've used many libraries and frameworks that wrapped it up into something more usable. My understanding is that the basic system is quite hard to use, and I guessed at one issue that might contribute to low adoption above (lack of lambda expressions in Java, making callback or promise based libraries tedious to use.)
  - nvm0n2 3y ago
    It's not hard to use exactly but it's low level. My point was that you can't just say "give me an async HTTPS server" or "give me an async JDBC connection", whereas because node started from scratch with this model then it's all async-capable. The new JVM Loom model is better though. No question.

nvm0n2 3y ago

Yes but was NIO really usable for most tasks? Even with things like Netty to plumb it all the way to web server frameworks, databases and so on took a while. Like if you wanted to do SSL+async then a lot of manual work was required before Loom (if you want to use the stdlib). Native image isn't related to async for sure. I meant more that it's a feature that people like from Go, which has both AOT/static binaries and also usermode threads.

noelwelsh 3y ago
I can't really comment on the usability of nio as I've never directly used it. I've used many libraries and frameworks that wrapped it up into something more usable. My understanding is that the basic system is quite hard to use, and I guessed at one issue that might contribute to low adoption above (lack of lambda expressions in Java, making callback or promise based libraries tedious to use.)
- nvm0n2 3y ago
  It's not hard to use exactly but it's low level. My point was that you can't just say "give me an async HTTPS server" or "give me an async JDBC connection", whereas because node started from scratch with this model then it's all async-capable. The new JVM Loom model is better though. No question.