4 ms·
I'm one of the people always critiquing the use of function coloring[0] to do async programming in most languages and defending the Go model as The Way. Howeve
by cube2222 5y ago
I'm one of the people always critiquing the use of function coloring[0] to do async programming in most languages and defending the Go model as The Way.
However, I totally get why Rust chose to go down that path. It's the way to go if you want to have zero-cost abstractions, even if it's a PITA. And since you're programming in Rust, you've already accepted that PITA's in the name of performance and low-level access are occasionally alright.
[0]:https://news.ycombinator.com/item?id=27545031 https://news.ycombinator.com/item?id=27545031
- kibwen 5y agoSeconded. If you're shipping a language with a meaty runtime, then save your users the headache and just include built-in support for green threads; your runtime probably already takes care of things like garbage collection and your users are fine with it, so they're unlikely to complain about not being able to squeeze out every last bit of single-threaded performance. But there are certainly niches for languages where users do expect to be able to squeeze out those last drops of performance, and Rust inhabits that niche. Different intended contexts can call for different approaches.
- rastignack 5y agoHowever rust is so hairy that it’s damn slow to develop in. You would expect database engine devs would pick rust to get those last drops of performance. Yet there is no production quality storage engine written in rust, whereas there are several of those in go. Ergonomics matter. Iteration time too. Rust fails hard there.