3 ms·

The features that each language offers are the same: threads, channels, and blocking I/O (though Rust has more features for safe concurrency--Rust prevents data

The features that each language offers are the same: threads, channels, and blocking I/O (though 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). What is different is the performance characteristics. In some cases, M:N will be more efficient; in some cases, 1:1 will be. 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.

ngrilly 7y ago
> 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 :)
- majewsky 7y ago
  > 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). Rust's async-fns compile into state machines, so they only allocate exactly the number of bytes that they need.
  - ngrilly 7y ago
    I know. I was writing about the 1:1 model without async/await :)

ngrilly 7y ago

> 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 :)

majewsky 7y ago
> 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). Rust's async-fns compile into state machines, so they only allocate exactly the number of bytes that they need.
- ngrilly 7y ago
  I know. I was writing about the 1:1 model without async/await :)