[Nullabillity]

There were already "user-mode" implementations of asynchronicity on the JVM for years (like Monix, cats-effect, Pekko (fka Akka), etc).

Loom has a worse API, is hidden from the user (what's preemptible and what will cause OS thread starvation? who knows!), and effectively ends up infecting the whole JVM with its complexity.

Go shares most of those downsides, but as a greenfield project (..heh) there's at least the expectation that all libraries play nice with their scheduler. They also try to hide FFI starvation by effectively running each FFI call in a dedicated OS thread[0].

There's also gevent/greenlet, which tries to bolt "colourless" M:N scheduling onto Python. It hasn't exactly taken the Python world by storm either, despite being far older than their native asyncio support.

Overall, I'd consider all three implementations of the approach to be dead on arrival.

[0]: See https://stackoverflow.com/a/28356944, it's a bit obfuscated but the overall effect is the same

[kaba0]

User-mode implementations are very easy to get wrong (you might accidentally call a blocking operation where you shouldn’t), and have indecipherable stack traces. How is Loom’s API bad? It literally reuses basically everything you know about Threads, seamlessly.

Also, Java has the luxury that almost no code makes use of FFI, so their impact is minimal.

[temporarely]

Kilim was the first for Java iirc.

Interesting point regarding scheduler and the interruptibility of FFI calls. Just thinking about it I don't see how this can be addressed. So definitely interested in learning here: what is the remedy to your criticism here beyond "document behavior"?

[funcDropShadow]

> Kilim was the first for Java iirc.

No, the JDK had builtin green-threads behind a command line flag around Java 1.1 on Solaris.

[temporarely]

fibers, not threads (regardless of color). "loom" ..

[zbentley]

> Go shares most of those downsides

Does it? Preemptability is pretty robustly solved in Go. While it's sometimes less efficient than I'd like, it's a far cry from the initial draft of virtual threads in java where a misplaced "synchronized" could sneakily starve entire executors. Even with CGo pinning (which, as you indicate, is rare due to the bulk of pure-Go libraries) I'm having trouble thinking of reasonable situations where full starvation or deadlock occurs rather than (admittedly unpleasant!) latency and queueing.

That said, Loom is quite new and deliberately iterative in approach, and the Java core folks are quite skilled, so I do expect to see substantial improvements in behavior and issue-detection tooling here over the coming years.

> I'd consider all three implementations of the approach to be dead on arrival

I'd argue that eventlet/greenlet failed for different reasons than the concurrency model or starvation risk (the monkeypatching approach just can't sustainably work in an ecosystem as big and native-code-dependent as Python's), hence Python's falling back to traditional async/await cooperative concurrency.

The Rust folks are struggling with the same choices here as well, further constrained by their requirements of a GC-less runtime with near-zero-overhead C FFI, which precludes them from using Go's approach. There was some great discussion of that here: https://news.ycombinator.com/item?id=39242962

[jen20]

If you consider Go to be "dead on arrival", I don't know what world you're living in.

[vips7L]

And the rationale for it being dead is… ffi? Something that 99% of all apps don’t use.