[dystroy]

Rust noob here. Can you please explain how removing '~' and '@' by moving the GC to a library makes async harder ?

[yccs27]

I suspect GP only read the title and not the article. A Java-style GC might make async code easier, but that never existed in Rust.

[BenoitP]

Lifetimes complicated. Having a proof of them at compile time is difficult. You can't prove everything for starters. A lot of patterns are just a no-go. Why not defer that to the runtime, and just observe which variables stick around (that's GC)

IO complicated. The cycle of doing code then waiting for IO is wasteful (sequentially you waste millions of CPU cycles waiting for the network to answer back). To max out usage of your hardware resources you could just aggregate IO requests with your compiler. Switching back and forth between code that uses IO, as IO request come back (that's async)

Problem is: switching back and forth between code that uses IO is recklessly hard wrt coming up with a proof of the lifetimes of the variables.

And a language/runtime _needs_ to have the trifecta of compiler/GC-or-memory-management/memory-model coherent and within the runtime.

compiler/GC-or-memory-management: the GC-or-memory-management needs to know who writes, who owns, who reads

GC-or-memory-management/memory-model: you need to know when and how you can read your writes, what are the rules

memory-model/compiler: you'll be managing memory barriers so that you can cram together sequences of writes that are compatible, for maximal performance

This trifecta dependence is foundation to a language/runtime, and a change to one affects the others quite deeply. Changing the compiler (bringing async here) affects the other ends and you can't do that when GC-or-memory-management is all over the place (as a lib, or god forbid in user hands)

I'm afraid async is just something unaffordable for a language that wants to be that close to the metal. And even then, async is just a bandaid for a costly threading IO model.

----

Come over to the dark side of Erlang, Go, and Java. We have small threads now. You can just block like there is no tomorrow, and the runtime will have a cheap back and forth. You can just forget about the lifetimes, as the GC will sweep after you (and concurrently, outside of the critical allocation path). Forget it all my friend. Java is love, Java is life.

[arghwhat]

Rather than those operators and how GC is done, I think the key aspect is how much easier async is in other languages that have easy automatic memory manage without ownership through garbage collection. Go and JavaScript/Dart are good examples.

But such models would also take away everything that makes Rust... Rust.

[baq]

it's not the things that were removed, it's the things you have to add to the source now to make it work within the limits of the borrow checker.

in the simplest case, you'd add Arc<..> everywhere @ used to be.