4 ms·
What makes me wary of jumping to Rust is the async stuff. From what I read, colored functions were introduced and most of the libraries that do useful stuff ado
by haolez 3y ago
What makes me wary of jumping to Rust is the async stuff. From what I read, colored functions were introduced and most of the libraries that do useful stuff adopted async and kind of force you to be aware of it in your own code.
For me, the perfect C++ replacement would be something like Go without the runtime burden. I'm not sure that this exists, so I use Go whenever I can and C++ in the ultra rare cases where I can't.
- pornel 3y agoThis "color" thing is a terrible miscommunication, because the original article is about two things that don't even make sense in Rust's context: • an architectural limitation of JavaScript which Rust doesn't have (in Rust you can wait for an async result in a sync function, or run CPU-heavy code from an async function). • a wish that languages had implicit magic that made sync and async calls look the same, which Rust intentionally doesn't want, because implicit magic is a terrible footgun in low-level code. It can be hidden in a high-level VM language that is in charge of all I/O, syscalls, and locks. But that is counter-productive for a low-level systems language for implementing I/O drivers, kernel syscalls, and custom locking primitives. So Rust is "purple". In reality Rust's async is awesome for what it is: a syntax sugar for state machines, which is able to flatten an entire call tree into a single fixed-size struct. Most other async architectures need at least one allocation per async call or per await, but Rust needs one allocation per the entire call graph with any number of async calls and awaits.
- techbrovanguard 3y agoIf you want to call an async function from a sync context, use `futures::executor::block_on`. Nobody is forcing you to use async.