Why asynchronous Rust doesn't work • Hacker News Board

Re: Why asynchronous Rust doesn't work

#421

Post by mratsim » Wed, Mar 10, 2021, 7:34 PM UTC

yxhuvud wrote: post #208

comex wrote: post #75

Earlier quoted context omitted.

> Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively made on the ground of "we want to ship async support as soon as possible" [1]. That is not an accurate summary of that comment. withoutboats may have been complaining about someone trying to revisit the decision made in 2015-2016, but as the comment itself points out, there were good reasons for that decision. Ma…

> First, Rust prefers unique ownership and acyclic data structures. You can make cyclic structures work if you use RefCell and Rc and Weak, but you're giving up the static guarantees that the borrow checker gives you in favor of a bunch of dynamic checks for 'is this in use' and 'is this still alive', One way to get around that is to instead of doing it like the very structureless async way actually impose lifetime r…

The structured parallelism movement predates structured concurrency by years and needs a similar push.

It's from 2004 with the X10 parallel language and then Habanero in Java via their "async-finish" construct

I wonder if your quote (structured XYZ or ABC considered harmful) is inspired by

- https://conf.researchr.org/details/etaps-2019/places-2019-pa...

Re: Why asynchronous Rust doesn't work

#422

Post by mratsim » Wed, Mar 10, 2021, 7:43 PM UTC

steveklabnik wrote: post #355

mratsim wrote: post #246

Earlier quoted context omitted.

It requires allocation if the coroutine outlives the scope that created it. Otherwise compiler are free to implement heap allocation elision (which is done in Clang). Now compared to Rust, assuming you have a series of coroutines to process a deferred event, Rust will allocate once for the whole series while C++ would allocate once per coroutine to store them in the reactor/proactor.

Rust never implicitly allocates, even with async/await. I have written Rust programs on a microcontroller with no heap, using async/await for it.

I don't think I've implied that allocation in Rust was implicit but that's a fair point.

Re: Why asynchronous Rust doesn't work

#423

Post by mratsim » Wed, Mar 10, 2021, 7:47 PM UTC

rcxdude wrote: post #337

moonchild wrote: post #207

Earlier quoted context omitted.

Not the OP, but my guess is that rust will do well for the sort of code that would be fast in c anyway: linear operations large, contiguous arrays. For pointer-chasing code, or code with lots of small objects, the little tricks you use in c aren't available (or at least, not as accessible), and the lack of gc and flexibility wrt references harms you.

Code with lots of small short-lived objects is often by default faster in something like rust, because stack allocation is very efficient (even compared to the bump allocation in a generational GC, which is much more efficient than heap allocation but worse than stack). If you have a lot of objects which can exist on the stack in your program, java will tend to do poorly in comparison. (and in general java will trade…

Does the borrow checker interfere with memory and object pools implementation?

Because if you require heap allocation for many short-lived objects, I expect this would be one of Java strengths unless you use an object pool.

Re: Why asynchronous Rust doesn't work

#424

Post by steveklabnik » Wed, Mar 10, 2021, 8:08 PM UTC

mratsim wrote: post #422

steveklabnik wrote: post #355

Earlier quoted context omitted.

Rust never implicitly allocates, even with async/await. I have written Rust programs on a microcontroller with no heap, using async/await for it.

I don't think I've implied that allocation in Rust was implicit but that's a fair point.

You said

> Rust will allocate once for the whole series

which, it will not.

It is true that some executors will do a single allocation for the whole series, but that is not done by Rust, nor is required. That's all!

Re: Why asynchronous Rust doesn't work

#425

Post by steveklabnik » Wed, Mar 10, 2021, 8:11 PM UTC

mratsim wrote: post #423

rcxdude wrote: post #337

Earlier quoted context omitted.

Code with lots of small short-lived objects is often by default faster in something like rust, because stack allocation is very efficient (even compared to the bump allocation in a generational GC, which is much more efficient than heap allocation but worse than stack). If you have a lot of objects which can exist on the stack in your program, java will tend to do poorly in comparison. (and in general java will trade…

Does the borrow checker interfere with memory and object pools implementation? Because if you require heap allocation for many short-lived objects, I expect this would be one of Java strengths unless you use an object pool.

"interfere" is a funny word, but you could do this in Rust. It's not super common, though the related technique of "arenas" can be, depending on domain.

Re: Why asynchronous Rust doesn't work

#426

Post by moonchild » Wed, Mar 10, 2021, 8:51 PM UTC

roca wrote: post #286

moonchild wrote: post #206

Earlier quoted context omitted.

> people also thought garbage collection was impossible in a systems language until Rust solved it No, they didn't. Linear typing for systems languages had already been done in ats, cyclone, and clean, the latter two of which were a major inspiration for rust. Venturing further into gc territory: long before rust was even a twinkle in graydon hoare's eye, smart pointers were happening in c++, and apple was experiment…

Perhaps more accurate to say "safe reclamation of dynamic allocations without GC was not known to be possible in a practical programming language, before Rust". The problem with languages like ATS and Cyclone is that you need heavy usage in real-world applications to prove that your approach is actually usable by developers at scale. Rust achieved that first.

Cyclone was a c derivative (I believe it was even backwards compatible), and ats a blend of ml and c. Ml and c are both certainly proven.

Cyclone was, and ats is, a research project; not necessarily intended to achieve widespread use. And again, obj-c was being used by apple in drivers, which is certainly a real-world application.

> without GC

I don't know what you mean by this. GC is a memory management policy in which the programmer does not need to manually end the lifetimes of objects. Rust is a garbage collected language. How many manual calls to 'drop' or 'free' does the average rust program have?

Re: Why asynchronous Rust doesn't work

#427

Post by omginternets » Wed, Mar 10, 2021, 9:25 PM UTC

jstrong wrote: post #95

omginternets wrote: post #73

Earlier quoted context omitted.

Mmmyeah, they said this about python too...

rust has avoided many pitfalls that python fell into. one example is the way that rust 2015 edition code works seamlessly with rust 2018 edition code, unlike the python2 -> python3 debacle. another is cargo vs pip/poetry/this month's python package manager. so, using python as an example isn't very convincing to me.

>so, using python as an example isn't very convincing to me.

That's because you're focusing on precisely the points where Rust has done better than Python, and conspicuously glossing over Python's asyncio debacle ... which looks exactly like Rust's.

In a nutshell, it works like this:

1. New syntax is introduced

2. We are told it's optional

3. The ecosystem adopts it, and it be comes de facto required

So right back at ya -- I am not convinced in the least by Rust's argumentation ;)

It's unclear to me how leadership can fix this. The cat is out of the bag, and the language must now contend with a second-order embedded syntax. Avoiding this becomes increasingly difficult as it is adopted in the ecosystem; just ask the C++ guys how they feel about exceptions.

Re: Why asynchronous Rust doesn't work

#428

Post by skohan » Wed, Mar 10, 2021, 9:27 PM UTC

filleduchaos wrote: post #342

skohan wrote: post #288

Earlier quoted context omitted.

I actually find ergonomic to be a very clear and intuitive term as it refers to programming language design decisions. And to use your cake analogy, the fact that a process is complex or laborious is orthogonal to the degree to which it is ergonomic. You could imagine baking a cake in a well organized kitchen with well designed, comfortable tools, or you could imagine having to stand on your toes and reach to the bac…

> I think this is a better analogy for ergonomics in programming languages. While it may be a better analogy, it doesn't really reflect the way the term is used. In my (admittedly anecdotal) experience, most people's complaints about ergonomics are more of expecting difficult things to be easier than they inherently are than of the actual quality of the tools they are presented with. People think they are complaining…

Or maybe it's a poorly designed mixer, or it's trying to be a mixer and a blender at the same time and not doing a good job at either task.

Sometimes complexity is a necessary consequence of the domain, and sometimes it's simply the result of poor design.

Re: Why asynchronous Rust doesn't work

#429

Post by pjmlp » Wed, Mar 10, 2021, 9:58 PM UTC

pornel wrote: post #418

pjmlp wrote: post #257

As I already mentioned multiple times, the future are tracing GCs with an ownership concept for niche use cases. Rust's ideal use case are the scenarios that use stuff like MISRA-C, kernel and drivers code. The design team has done a wonderful work pushing for affine types into mainstream, however outside of forbidden-GC scenarios, the productivity loss versus any kind of automatic memory management approach, isn't w…

Single ownership and deterministic destruction are quite useful on their own though, outside of just memory management. I wouldn't call them niche. Rust makes use of them all the time. Deterministic destruction is obviously very useful for resource management, and not just files and database handles, but also locks and scope guards. Single ownership allows working with mutable data without dangers of shared mutabilit…

Most languages with automatic memory management also offer language features for deterministic destruction.

Re: Why asynchronous Rust doesn't work

#430

Post by roca » Wed, Mar 10, 2021, 10:07 PM UTC

moonchild wrote: post #426

roca wrote: post #286

Earlier quoted context omitted.

Perhaps more accurate to say "safe reclamation of dynamic allocations without GC was not known to be possible in a practical programming language, before Rust". The problem with languages like ATS and Cyclone is that you need heavy usage in real-world applications to prove that your approach is actually usable by developers at scale. Rust achieved that first.

Cyclone was a c derivative (I believe it was even backwards compatible), and ats a blend of ml and c. Ml and c are both certainly proven. Cyclone was, and ats is, a research project; not necessarily intended to achieve widespread use. And again, obj-c was being used by apple in drivers, which is certainly a real-world application. > without GC I don't know what you mean by this. GC is a memory management policy in wh…

Cyclone wasn't backwards-compatible with C.

ATS is not just "a blend of ML and C", it has a powerful proof system on top.

You can't just say "well, these languages were derived from C in part, THEREFORE they must be easy to adopt at scale", that doesn't follow at all.

Yes, Cyclone and ATS were research projects, that's why they were never able to accumulate the real-world experience needed to demonstrate that their ideas work at scale.

Objective-C isn't memory safe.

By "GC" here I meant memory reclamation schemes that require runtime support and object layout changes ... which is the way most people use it. If you use the term "garbage collection" in a more expansive way, so that you say Rust "is a garbage collected language", then most people are going to misunderstand you.