3 ms·
> As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would app
by stymaar 10y ago
> As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would appear that you want something that handles async I/O, but this comment seems to indicate otherwise, and Rust does have pretty nice primitives (in the stdlib, and in rayon/crossbeam) for general parallel programming.
Since he mention Go and Erlang, I think what the gp just wishes Rust had a built-in solution for M:N threading.
Whether M:N threading is nicer than async APIs is highly subjective though. (I'm talking about ergonomics here. I think it's widely accepted that async is more efficient when performance really matters)
- Manishearth 10y ago> I think what the gp just wishes Rust had a built-in solution for M:N threading. Yeah, but then they say that they doesn't want concurrency to be based on async io primitives, which is exactly what Go does IIRC.
- stymaar 10y ago> which is exactly what Go does IIRC. Under the hood, I guess yes. But in Go, the developer always use blocking API and the runtime does the magic with the async stuff. Some people find it easier to reason about code written this way.
- lobster_johnson 10y agoBoth Go and Erlang are based on blocking, synchronous I/O primitives combined with asynchronous communication between the green threads that use them. It's a lot easier to reason about than event-based I/O.