3 ms·
Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales fro
by ViewTrick1002 5mo ago
Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead.
History:
This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading.
https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...
- sysguest 5mo agowell rust async is 'still evolving' right now it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)
- ViewTrick1002 5mo agoAgree. There's stuff missing, and there are problems which likely are "multiple Phd theses" level to solve cohesively. Either in Rust or a successor language when the problem space has been explored. For me the most annoying part are the footguns async Rust introduces, which Rust generally is blessedly empty of compared to e.g. Go or other languages. Like for example, cancellation safety, dealing with "long running" futures, cleanly terminating a program, deadlocks at a distance [1] and others I'm forgetting now. [1]: https://rfd.shared.oxide.computer/rfd/0609 https://rfd.shared.oxide.computer/rfd/0609
- deleted 5mo ago[deleted]