Hacker News Reader

Comment by kosolam | Hacker News Reader

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

View on HN

If you want to use an async framework without sacrificing simplicity, look into Elixir/Erlang and the BEAM.

Does this mean one doesn’t need to use reactor with spring and can rely on the non-reactive method and still get great performance?

Once spring changes over their internal implementation, yes. In the meanwhile there are already Loom-aware frameworks out there like Helidon Nima.

If you want to run concurrent io requests, don't you still need to use an async framework and all the fork/join logic? I suppose the slow and naive way is now easier to let limp along as you won't run out of threads?

Why would you need an async framework? All blocking I/O in the Java runtime has been changed to yield in a virtual thread.

They added the structured concurrency package because you still need some kind of async framework for concurrency.

Maybe the confusion is just the term "framework" as opposed to API? I don't mean a third party library is needed. The built in JDK alone is sufficient but you're still juggling promises/futures and the like.

You don’t really need anything, they just make forking and subsequent joining+exception handling easier. You can just use the decades old thread api over virtual threads as is if you wish, but this “structured concurrency” concept, similar to goto vs structured control flow will make it much more productive and easier to reason about.

Also true, but "use the decades old thread api" shouldn't count as a simplification, right?

It should when you can just block left and right.

Again, my point is that you often won't want to be blocking. You'll still want to run multiple async calls concurrently, and to do that the syntax is not the familiar synchronous style. You still need to use more complex apis.

The complexity of an async lib/framework such as i.e. projectreactor stems from that your code stops being linear. And so is the dataflow. This is the core of the issue. You trade simplicity for performance. Using futures you can still write simple linear code. The problem is that thread based execution doesn’t scale well when the threads are mostly waiting for io, such as i.e. an http request. That is, it was a problem until virtual threads arrived.

JVM itself would do async I/O as needed using whatever API the underlying OS provides. Your own I/O code would be straightforward and synchronous. Nothing will run out of threads.

The key point is concurrent calls. If you're calling out to multiple microservices or what have you (the case where you would actually hit 1M threads in the first place) you'll want to do that in a concurrent way with futures or fork/join and not in a synchronous style.

One could argue that automatic promise wrapping and an await keyword ends up giving you cleaner, more simple code (despite the coloring).

The reason I dislike async/await is that the code doesn't clearly express what it actually does. I also dislike asynchronicity built directly into the language. It's just one more piece of context you have to keep track of, and the more context you need in your head to understand the code, the greater the potential for bugs, imo. It is good that Java forces one to explicitly write out their intentions.

I really like the approach Java has chosen: keep the language itself as dumb as possible, but add all the niceties to the standard library and runtime.

Because Java did not have a good async model for decades, most Java apps are thread-intensive (thread-per-client) and there's an enormous amount of code that can't easily be refactored into async. Light-weight threads help save all that thread-per-client code from the ash pile of history.

But in general it's best to write async code from the get-go because that forces the programmer to compress application state rather than inefficiently smear parts of it on the stack. Better state compression (because smaller stacks) -> smaller memory footprint per-client (or whatever) -> faster (because of higher cache hit ratios because of less cache thrashing because fewer memory accesses).

We are made of meat. It’s rarely worthwhile to sacrifice developer effort to conserve hardware, and if you do manage to break even today, you probably won’t in the future. Async Java was pretty painful and only penciled out because the cost of a million native threads was just ludicrously higher than everything else.

Yes, for Java the ergonomics of async will probably never be there. More generally however, it doesn't have to be so.

Reply on news.ycombinator.com