3 ms·
> My only experience with Rust has been synchronous It is a shame that the dominance of the "async/await" paradigm has made us think in terms of "synchronous"
by worik 2y ago
> My only experience with Rust has been synchronous
It is a shame that the dominance of the "async/await" paradigm has made us think in terms of "synchronous" or "async/await"
> Think about it, if you write a lot of async code, chances are you have a ton of latency, waiting on I/O, disk, network etc
Yes. For almost all code anyone writes blocking code and threads are perfectly OK
Asynchronous programming is more trouble, but if trying to deal with a lot of access to those high latency resources asynchronous code really shines.
The trouble is that "async/await" is a really bad fit for rust. Every time you say `await` you start invisible magic happening. (A state machine starts spinning I believe in Rust - I may be mistaken)
"No invisible magic" was a promise that Rust made to us. What you say is what you mean, and what you mean is what you get.
No more, if you use async/await Rust
I really do not understand why people who are comfortable with "invisible magic" are not using a language with a garbage collector - that *really* useful invisible magic.
Asynchronous programming is the bees knees. It lets you get so much more from your hardware. I learnt to do it implementing telephone switching systems on MS-DOS. We could run seven telephone lines on a 486, with DOS, in (?) about 1991.
Async/await has so poisoned the well in Rust that many Rust people do not understand there is more to asynchronous programming than that
- the__alchemist 2y agoI notice this as well; there is a false dichotomy of "Async/Await" or "blocking". I see this in embedded too. I think a lot of rust embedded programmers learned on Embassy, and to them, not using Async means blocking.
- omani 2y agocan you elaborate on this?
- the__alchemist 2y agoWriting programs that perform multiple tasks asynchronously can be done in many ways. It is a broad and important tool in software, and the Async/Await language is only one way to do it. Examples: - Multiple cores - DMA or other dedicated hardware - GPU programming - Distributed systems (e.g. the CAN network in your car) - Threads - Interrupts - Event loops - Coroutines
- zavec 2y agoIs the alternative the more traditional spawning threads and using channels, or is there another paradigm? That's definitely something I'd be interested in learning more about.
- onjectic 2y agoI think they mean that there is more than one asynchronous paradigm. Actors is one alternative I can think of.
- palata 2y agoWhere an actor has its own thread and communicates with a channel, right?
- pdimitar 2y agoNot necessarily, a lot of actors can be sharing the same OS thread and be preemptively switched away from when they hit a certain limit of instructions or start an I/O call. Erlang demonstrates this very well because it works there without a glitch 99.99% of the time (and the remaining 0.01% are because of native code that does not yield control).
- GolDDranks 2y agoThere is also readyness-based polling in a loop, without the async/await sugar.
- _flux 2y agoHowever, if you need a state machine, async/await is a super-elegant way to express it. No other language provides as nice way to do it. I believe best you can do in other languages is using continuations as the state.
- worik 2y agoState machines are the easy part.
- metaltyphoon 2y agoC# async transform into a state machine too.
- rcxdude 2y ago>very time you say `await` you start invisible magic happening. (A state machine starts spinning I believe in Rust - I may be mistaken) It's more that an async function in Rust is compiled completely differently: it's turned into a state machine at that point, with the code between 'awaits' being the transitions. In and of itself, it's not actually particularly difficult to grok (I'd say you have about as much an idea of what the resulting machine code looks like as with an optimized non-async function), the headaches are all in the edges of what the language can currently support when compiling under this model.
- kod 2y ago> "No invisible magic" was a promise that Rust made to us. Honest question, where did you get that promise from? The 1.0 release didn't really emphasize that: https://blog.rust-lang.org/2015/05/15/Rust-1.0.html https://blog.rust-lang.org/2015/05/15/Rust-1.0.html The current rhetoric is more about empowering more people to have confidence in systems programming: https://doc.rust-lang.org/book/foreword.html https://doc.rust-lang.org/book/foreword.html Some of graydon's ideas starting almost a decade before 1.0 might have included that https://github.com/graydon/rust-prehistory/blob/df8cc964772b36fe120df51eb5ee408b6dc2953a/doc/rust.texi#L126 https://github.com/graydon/rust-prehistory/blob/df8cc964772b... but his recent posts on what he would have done differently if he was BDFL include a bunch of stuff that's arguably more magical, not less: https://graydon2.dreamwidth.org/307291.html https://graydon2.dreamwidth.org/307291.html
- zavec 2y agoNo invisible magic sounds more like something I've read about zig, maybe they were confusing it with that?