zlacker

>>todsac+(OP)
> I’m happy with how Rust turned out.

I agree, with the possible exception of perplexing async stuff.

>>mkorna+bVl
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.

>>echelo+01m
> 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?

>>ori_b+VVm
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.

>>simona+jnn
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.

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