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.

>>stevek+RIn
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?

>>jacque+rLn
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.