[jayd16]

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.

[kosolam]

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.

[kaba0]

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.

[jayd16]

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

[eklavya]

It should when you can just block left and right.

[jayd16]

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.