Comment by worik | Hacker News Reader

Comment by worik | Hacker News Reader

Parent Full thread

> 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

I 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.

can you elaborate on this?

Writing 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

Is 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.

I think they mean that there is more than one asynchronous paradigm. Actors is one alternative I can think of.

Where an actor has its own thread and communicates with a channel, right?

Not 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).

There is also readyness-based polling in a loop, without the async/await sugar.

>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.

> "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

The current rhetoric is more about empowering more people to have confidence in systems programming: 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/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

No invisible magic sounds more like something I've read about zig, maybe they were confusing it with that?

However, 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.

State machines are the easy part.

C# async transform into a state machine too.

Reply on news.ycombinator.com