Conversation

Frank ⚡
@jedisct1
“What should I use to do async I/O in Rust *today*?” is a question I don’t have any solid answer for. The current state is a clusterfuck of different approaches. If you need async I/O for a real project *today*, use Go.
2
4
Frank ⚡
@jedisct1
Romio doesn’t look bad. But like all other similar projects, it will eventually be abandoned. The lesson here is that new languages should provide built-in async I/O, from day one. And stick to it. Even if it sucks. Give us a solid and stable base for a necessary feature.
2
5
Frank ⚡
@jedisct1
Go goroutines and channels may suck and not appear to be “the best solution”, are not “zero abstraction” and are not “safe”. But they work. They are stable. They are easy to understand. They have been around forever. They are good enough for most real-world problems.
2
2
Daniel Micay
@DanielMicay
Replying to
@jedisct1
Rust started out with native M:N threading but it was counter to the goals of being a viable systems language. It needed 1:1 threading to able to compete on performance with C, interact well with other languages, etc. If it didn't make these choices, what would be the use case?
1
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
and
@jedisct1
Rust is trying to be something much different from Go. Despite offering more fancy high-level language features, it's a lower-level language. It dropped features like M:N threading and garbage collection because they compromised viability in the main niche it was aiming to fill.
1