[echelon]

I write and use mostly async code, and I cannot for the life of me understand the async hate.

What do you want Rust to do differently?

What language does async right?

How did Rust not reach its async goals?

Rust even lets you choose the runtime you want. And most big libraries work with several runtimes.

[mkornaukhov]

I do write mostly async code, too.

There are several ~~problems~~ subtleties that make usage of Rust async hindered IMHO.

- BoxFuture. It's used almost everywhere. It means there are no chances for heap elision optimization.

- Verbosity. Look at this BoxFuture definition: `BoxFuture<'a, T> = Pin<Box<dyn Future<Output = T> + Send + 'a>>;`. It's awful. I do understand what's Pin trait, what is Future trait, what's Send, lifetimes and dynamic dispatching. I *have to* know all these not obvious things just to operate with coroutines in my (possibly single threaded!) program =(

- No async drop and async trait in stdlib (fixed not so long ago)

I am *not* a hater of Rust async system. It's a little simpler and less tunable than in C++, but more complex than in Golang. Just I cannot say Rust's async approach is a good enough trade-off while a plethora of the decisions made in the design of the language are closest to the silver bullet.

[ori_b]

> What do you want Rust to do differently?

Lean into being synchronous. Why should I have to manually schedule my context switches as a programmer?

[simonask]

Because async and sync programming are two fundamentally different registers. There are things you can do in one that you can’t with the other, or which have dramatically different tradeoffs.

As an example: Call N functions to see which one finishes first. With async this is trivial and cheap, without it it’s extremely expensive and error-prone.

[jacquesm]

The actor model proves that that isn't really as fundamentally a difference as you make it out to be. Write synchronously, execute asynchronously, that's the best of both worlds. To have the asynchronous implementation details exhibit themselves at the language level is just a terribly leaky abstraction. And I feel that if it wasn't a fashionable thing or an attempt to be more like JavaScript that it would have never been implemented in the way it was in the first place.

Async makes everything so much harder to reason about and introduces so many warts in the languages that use it that I probably think it should be considered an anti-pattern. And I was writing asynchronous code in C in the 90's so it's not like I haven't done it but it is just plain ugly, no matter what syntactic sugar you add to make the pill easier to swallow.

[steveklabnik]

The actor model isn’t possible to enforce in a systems programming language, in my opinion.

[jacquesm]

What do you base that opinion on?

The fact that it hasn't been done?

Or that you can't do it in a systems programming language whose main intent is to replace 'C'?

I don't want to start off with a strawman but in the interest of efficiency:

Because C is far from the only systems programming language and I don't see any pre-requisites in the actor model itself that would stop you from using that in a systems programming language at all. On the contrary, I think it is eminently suitable for systems programming tasks. Message passing is just another core construct and once you have that you can build on top of it without restrictions in terms of what you might be able to achieve.

Even Erlang - not your typical first choice for low level work - is used for bare metal systems programming ('GRiSP').

Maybe this should start with a definition of what you consider to be a systems programming language? Something that can work entirely without a runtime?

[steveklabnik]

Sure, you can absolutely build systems with the actor model, even some embedded or bare metal cases. But Erlang isn't written in Erlang. I'm talking about the languages that you implement Erlang in.

Yes, I think "entirely without a runtime" in the colloquial sense is what I mean. Or "replace C" if you want.

[ori_b]

Do you mean RPCs, or dispatching to threads?

If not, your async code is a deterministic state machine. They're going to complete in the same order. Async is just a way of manually scheduling task switches.