I believe Golang uses a similar model but much more simple to use. Uncolored async is the way to go

I'm of two minds on this point. Uncolored async is simpler language design and works well for _most_ cases but provides way fewer guarantees than colored async, with the potential to break badly in some cases.

For instance, there are many system-level data structures that are not allowed to migrate from one thread to another (e.g. Linux mutexes or Rust's Rc) or sometimes from one core to another. If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all.

Which means that you can't be a system programming language (for some definition of system programming).

By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .

> e.g. Linux mutexes

You don't want to use blocking mutexes anyway with async.

> or Rust's Rc

This is only half true. The danger is that two `Rc` that point to the same data are in different threads. But it should be safe to move all of them at once from one thread to another, which is exactly the case if all the `Rc`s involved live inside a `Future`. The problem is that this is a non-local property that's hard to encode in the type system.

> By the way, if you wish to test uncolored async in Rust, you can find an implementation here: https://github.com/Xudong-Huang/may .

FYI that's known to be unsound due to thread locals. And more generally it doesn't seem to give much attention to safety (see for example how it allowed unsound scoped tasks, or the fact it allows doing unsafe operations in some of its macros due to wrong scoping of `unsafe` blocks).

> If you adopt uncolored async (unless perhaps you're using a thread-per-core scheduler), you just can't manipulate these data structures. At all.

A simple call to https://pkg.go.dev/runtime#LockOSThread solves that.

Pay the cost of backwards compat when you need it, don't pay it when you don't need it.

Go's approach to async programming is indeed simpler, but its FFI and handling of stateful coroutines can introduce complexity and overhead when bridging with external code. Using CGO is slow because it requires synchronization of the coroutine state between libc and Go. Everyone avoids CGO whenever possible, so it is not a solution.

Rust chose a different path that is not more complex, but the complexity lies elsewhere.

Just an extra bit of clarity: the relative slowness of CGo calls is a conscious trade-off that enables Go threads to be much lighter weight. It's not an inherent aspect of the design, but a trade-off you pay for wanting more lightweight green threads. Choosing to not follow the age old C ABI internally means you have to bridge that gap if and when you come to it.

That I can easily believe. Someone should make a benchmark of how many requests you can serve from a java backend compared to a rust backend that's heavy on IO and network.

Sure, we did that in 2016 when we first created the Future abstraction: http://aturon.github.io/blog/2016/08/11/futures/

Java virtual threads shipped between 2021 (preview) and 2023 (final).

Yeah an 8 year old benchmark doesn't mean much, both languages/platforms surely have evolved greatly and I would not surprised that on many meaningful workloads there is some parity.

It wouldn't stop the hype, it never does.

I never understood the fascination for working with cutting edge languages; to me it just increases the likelihood that you're going to find language errors or library errors and get tied up for ages helping to refine the environment. Plus the relatively small size of the developer community and supporting literature available.

Maybe it's a dog people thing, the sort of people that get into it are the sort of people that want to go home and have a dog with infinite energy bouncing up and down all the time.

Just exhausting to even think about.

> cutting edge languages;

Whatever about anything else, Rust has definitely moved past "cutting edge"

I have been actually professionally working with Rust for the last 2 years, and most recently on certified safety systems.

But I'm always thinking that the JVM is a pretty solid platform that has not yet reached its full potential. It gets a bad rap because of the hellhole that enterprise software is. But come on, look at android, look at games like Minecraft. Solid projects, written in large part in Java.

Describing Minecraft as "solid" makes me very scared reading "certified safety systems". Minecraft is the most standard possible example of Java's badness and bloat. It's explicitly what software should strive not to be.

It's a game first and foremost, and it mostly works, quite well, with multiple players. It's a completely different set of requirements from safety software.

And people write mods for it and have had success. If that is not solid what is. For real what's so bad about minecraft, it even runs on a relatively old laptop of mine with 8 gigs of RAM without any lag.

In most safety software you can't even use dynamic memory. Maybe a lot of the software we write in that domain would be considered "bloat" in others, but I don't know what are the constraints that Minecraft faces that drove it to be implemented the way it is. But despite the bloat, they managed to do a lot.

> For real what's so bad about minecraft, it even runs on a relatively old laptop of mine with 8 gigs of RAM without any lag.

When Minecraft came out, 8G of RAM would be pretty much the highest-end system you can buy. It's really not the flex you think it is.

In terms of the opposite direction from Minecraft in stability is Factorio, which can easily run on a multiplayer server for a gaming group on a potato of a computer and whose high-end multiplayer record is well over 500.