I saw this on Hacker News
I am wondering what people think?
Especially async/await devotees. This could really help with some of the very difficult memory management problems.
I was very interested to see this and the video here.
Would a garbage collector help?
Can you elaborate a bit on what you're asking? I don't really see async cancellation, async drop, and garbage collection as being all that interdependent.
The garbage collector results are certainly interesting, but its direct integration with rustc makes it much harder to actually adopt without buy in from the rust project.
My POV is that of a language user, not designer.
Having used async/await in Rust and in Dart or Typescript the difference is startk.
In Rust I am forever having to use "magical incantations" to get async/await to work, to the extent I do not use it for asynchronous programming, it is too much trouble. In Typescript and Dart I have had none of those problems
Watching the talk on cancellation makes me think that Rust is going down the wrong track here.
My experiences using async/await in those three languages makes me think that an important part of the puzzle is a garbage collector. Trying to manage memory, as we do in Rust, without control over what code is running, as we do not with async/await, seems like an impossible task.
So I wonder if Rust should bifurcate and async/await should add garbage collection to the runtime? Would that heal the problems with memory management and cancellation?
I do a lot of asynchronous programming, in C back in the day, and in Rust now, mostly with callbacks and/or state machines, and I do not see what the problem is that async/await is trying to solve. It does not seem hard to me (callbacks and state machines). I think that puts me in a minority.
I am distressed that asycn/await is becoming the default both where asynchronous programming makes sense and where it does not.
That would be a completely different language IMO.
I don't see what GC has to do with async cancellation.
My experience, mainly with C# is the opposite. Yes, the GC makes things a bit easier but it is very very easy to introduce subtle concurrecy bugs between tasks running on different threads: nothing in the language or in the implementation of async helps you - all locking and synchronization should be done by hand. Rust just works.
I don't know how introducing a GC would impact Rust async/await but I fear that having long-lived objects and non-deterministic Drops would make things more complicated, not simpler.
I'm curious as to what troubles you have and what "magical incantations" you have to use. Any little examples? I ask because I have yet to find writing async Rust harder than writing sync Rust.
Except perhaps when interfacing the async world to the sync world. But that was a problem for me in Python as well.
Similarly, I have yet to see that problem. Any examples?
Yes.
Async/await rust is half way there already - which is my point
With a garbage collector the GC would handle the cancellation, would it not? I am seriously out of my depth, so I may have the wrong end of that stick.
When I say "garbage collector" I am not being specific, I am being general about language run-times. Async/await already requires a run time which is how the programmer loses control of the code that is actually being executed. It is not the only way to loose that control, but loss of control is a feature, not a bug, of sync/await. I am proposing going the full distance and adding more resource management to the run time.
It would mean giving up on async/await real time programming or async/await embedded programming, but that is a tiny tiny fraction of code being written. For most use cases it would be much better if my experience of the three languages is any guide.
That right there is a show stopper. For me at least. In my world real-time and or embedded is very important. It's one of the main reasons I even considered to look at Rust in the first place. "systems programming" and all that.
Real-time and embedded Rust may be as tiny fraction of code being written at the moment but it is rapidly growing as far as I understand. It's important.
More generally, in a hand waving way, I don't see the point of trying to make Rust into another Java or C#. If they are what you really want they are very much still there.
Also, as a fraction of code being run in the world, embedded vastly outnumber "normal" computers. For a start, every "normal" computer or phone has multiple embedded microcontrollers in them: SSD controller, fan controller, keyboard controller. Wifi/lan/cellular all have at least one controller as well each. And a bunch more.
Add on top of that: washing machine, dishwasher, fridge, many microcontrollers in cars, trains, airplanes, etc. And then there is all the code that is realtime but not running on microcontrollers: industrial control systems, traffic lights, etc.
So in a very real sense, this segment is the most important in programming. Especially since if a game crashes, it may annoy users but doesn't really matter in the grand scheme of things. If the break controller in you car freezes there is a significant risk of death.
Embedded is in fact "most use cases"
Seems likely, or at least a huge percentage of use cases.
At the other extreme data centres are huge and devouring enormous amounts of energy. The need for efficiency is increasingly pressing there as well.
The issue is not really handling the cancellation, it's cancelling at the right point and cleaning up afterwards. This isn't something that a GC or runtime can do for you.
It would mean having two incompatible languages in one. You would have to make sure that the GC and runtime can be disabled. People will want to make sure that their dependencies don't enable the runtime/GC. The runtime implementation will have to make sure it doesn't break the assumptions that unsafe code make and so on.
That is what we have.
I want two incompatible languages.
Ok. Still out of my depth, but I thought that is exactly what a run time environment can do for you? I thought it was what people in the asyc/await world want from Rust's async/await runtime.