Also, I don’t feel like that’s true: Rust has the exact same non blocking IO primitives in the stdlib as any other systems language: O_NONBLOCK, multiplexers, and so on. Combined with async/await syntax sugar for concurrency and backends like Tokyo, I’m not sure how you end up at “rust IO is still blocking”.
Comments
It still wouldn't lead to proper Rust concurrency safety, because their IO is still blocking.
What’s blocking IO have to do with this topic?
Also, I don’t feel like that’s true: Rust has the exact same non blocking IO primitives in the stdlib as any other systems language: O_NONBLOCK, multiplexers, and so on. Combined with async/await syntax sugar for concurrency and backends like Tokyo, I’m not sure how you end up at “rust IO is still blocking”.
Lock-freeness is an important step to concurrency safety. Rust falsely calls itself concurrency safe.
For a system language it's great to finally have a lock free library for some containers, but that's still not safe.