[socialdemocrat]

Ah yeah, I am not sure everybody know me what “colored” means but I remember when comparing a C# solution using async with a Go solution using channels and Go routines I finally understood why people keep raving about concurrency in Go. It composed very nicely while any language following the popular async/await approach turns into a total mess. I guess async/await looked good years ago because we compared it with managing POSIX threads manually. That sucked.

[curun1r]

It's worth noting that Rust's Async functionality starts with very different priorities from Go's goroutines. Rust, as a systems language, made lack of overhead (allocations, etc) the highest priority. It's part of Rust's overall zero-cost abstractions ethos. Goroutines are just never going to be zero cost. Go chose to prioritize the interface to the programmer, which is much more a part of Go's ethos around being simple.

There's nothing wrong with either approach, they just have different trade-offs because their goals are different. Rust's approach will sometimes push complexity onto the programmer to handle. But it can be made to perform better and more predictably than the Go equivalent. This might not matter if you're not pushing the performance envelope, but if you are, Rust makes that possible in a way that Go simply doesn't. You'd never want to write code using goroutines for an embedded device with limited CPU/memory, but Rust's async is already proving useful for these sorts of projects.

However if you can tolerate the performance overhead that Go imposes, giving the programmer a simpler mental model can easily be worthwhile. Technology is all about trade-offs and you have to choose the right tool for the job.

[djur]

Async/await was intentionally chosen by a lot of languages well after Go had become popular. Rust once had Go-style concurrency and abandoned it in favor of its current model.