> blocking I/O Rust I/O are strictly similar to Go when using 1:1 OS threading, but become conceptually different when using async/await. > Rust has more feat

> blocking I/O Rust I/O are strictly similar to Go when using 1:1 OS threading, but become conceptually different when using async/await. > Rust has more features for safe concurrency--Rust prevents data races statically, while Go is not even memory safe in the presence of such races Agreed. That's a big advantage of Rust. > What is different is the performance characteristics. Performance is a feature. It's significant enough to justify using one language or the other depending on the project at hand. > In some cases, M:N will be more efficient; in some cases, 1:1 will be. The main advantage of the M:N model, compared to the 1:1 model, is the memory usage, because each goroutine starts with a small stack (a few kB). It makes possible to start a larger number of M:N goroutines than 1:1 threads. > But just as I wouldn't say Go is lacking FFI features because M:N makes cgo slow, I wouldn't say Rust is lacking concurrency features. Go's FFI works but is slow. It's a well known fact. Rust's concurrency story is not stabilized yet (areweasyncyet.rs). It's a fact too. I don't see a problem with acknowledging both :)