3 ms·
Rust will thrive despite the PLT coloring debate. Async frameworks often dominate through winner-takes-all dynamics. Most blog posts on async coloring are prete
by infamouscow 1y ago
Rust will thrive despite the PLT coloring debate. Async frameworks often dominate through winner-takes-all dynamics. Most blog posts on async coloring are pretentious nonsense, and I've faced heavy moderation here for calling out their intellectual bankruptcy. The completely brain dead moralizing arguments from the ignorant deserve intense derision regardless of what HN's official rules are.
Real world software ecosystems evolve slowly, requiring years of debate to shift.
- From HN's most outspoken Rust critic
- tomsmeding 1y agoGP's complaint wasn't about the coloring, but about the fact that the basic async API is not enough for most tasks, so you don't only have colored functions, you're now also bound to an async runtime. The world would be much better if most async rust code was agnostic of the async runtime, despite still having the colored functions issue.
- simonask 1y agoSure, the situation is just vastly better - even now - than standardizing the wrong solution. Each widely used async runtime in Rust has different solutions for a number of problems, and the choice isn't obvious. For example, `tokio::spawn()` returns a task handle that lets the task keep running after the handle is dropped. `smol::spawn()` cancels the task when the task handle is dropped. General async cancellation requires infrastructure mechanisms, and there are multiple reasonable designs. Letting things settle in the ecosystem is a great way to find the best design to eventually incorporate in the standard library, but it takes time.