[mrsilencedogood]

Damn, still not structured concurrency full release. Really looking forward to that one.

Happy to see Scoped Values here though. That'll be big for writing what I'll call "rails-like" things in Java without it just being a big "static final" soup in a god-class, or having a god object passed around everywhere.

[pjmlp]

Much better this way with previews, than the mess C++ is having nowadays with standardising features without implementations.

[jayd16]

I hope structured concurrency ends up feeling better than async/await with less sugar. The examples do not instill confidence, but we shall see.

[dwaite]

The structured part is somewhat like using for and while loops rather than goto statements - it uses block scope to make it easier to reason about how concurrent code is compartmentalized.

However, you still have concurrent code. The example given uses futures rather than async/await, and so the thread blocks waiting for these other threads to complete.

The Java alternative to async/await is the virtual threads. Since they are not GC roots and the stack is a chain of heap-allocated objects, the idea is that they can have significantly lower overhead in terms of memory usage for small tasks. Rather than the compiler generating heap objects to store intermediate state, it just uses a virtual thread's stack.

However, even without async/await syntax you still have equivalent concepts. Since the compiler doesn't have native structured concurrency, it is emulated by putting tasks in lambdas. You fork off subtasks, and do a blocking get() to resolve the futures for their results. Heavy use of fork(), run() and get() aren't necessarily better than async and await keywords.

One concern I have is that Java virtual threads are supposedly preemptive, not cooperative. This means you will have less guarantees around concurrent modification than you would with a typical async/await system running cooperatively on an executor. Several languages willing to make more core changes around adding async/await have gone as far as to also integrate actor functionality to help developers write concurrency-safe code. I don't see Java being able to provide developer help/diagnostics here like other languages can.

[pjmlp]

Unfortunately on .NET side, TPL Dataflow doesn't get enough love.

[jayd16]

They added an async Channel and its actually pretty nice to work with, at least.

[colonCapitalDee]

Agreed. This is how I feel using it: https://xkcd.com/297/. It's from 2012! I hadn't even written my first `public static void main(string[] args)` then.

My favorite parts of TPL Dataflow are using Channels + Encapsulate to create custom blocks, backpressure, and parallel execution while maintaining ordering. Great library. I sometimes wonder if it would be possible/useful to implement a TPL Dataflow 2.0 on top of Channels.

[dionian]

I would be shocked if they came up with something that made me want to move away from ZIO.

[monkeyelite]

It looks like a far smarter approach than async/await