4 ms·
I love Rust, but async is a hot mess and you cannot just write async code the same way that you write sync code. I'm getting more convinced that mixing the two
by mmastrac 3y ago
I love Rust, but async is a hot mess and you cannot just write async code the same way that you write sync code. I'm getting more convinced that mixing the two is a bad idea, and that Go's approach of making everything sync with a single async channel primitive might be right.
I'm currently plumbing through some logic to call a sync method on a struct that implements Future and it's... an interesting challenge.
While we can make zero-cost async abstractions somewhat easy for users, the library developers are the ones who suffer the pain.
- staunton 3y agoLibrary developers can afford to deal with complexity much more than users of libraries. Offloading such work on highly skilled people developing the basic infrastructure is surely the right approach.
- riku_iki 3y agomany of these libraries then are debugged and troubleshooted by users..
- deleted 3y ago[deleted]
- mmastrac 3y agoI totally agree that library developers are the ones who _can_ handle complexity, but I have found even some of the top Rust devs are making async mistakes -- either the APIs are not correct from an async perspective, or there are basic bugs like losing wakers. The latter is so common it's not funny.
- Yoric 3y agoI've seen one wasm VM for Rust that offered what looked like transparent M:N, which should solve (in that case) most async difficulties. We'll see how that evolves.
- mike_hearn 3y agoWhich one? I wonder what its performance is like. A good candidate for this is Graal. It can compile (JIT/AOT) both WASM and also LLVM bitcode directly so Rust programs can have full hardware/OS access without WASM limitations, and in theory it could allow apps to fully benefit from the work done on Loom and async. The pieces are all there. The main issue is you need to virtualize IO so that it goes back into the JVM, so the JVM controls all the code on the stack at all times. I think Graal can do this but only in the enterprise edition. Then you'd be able to run ~millions of Rust threads.
- rapnie 3y agoCurious too. I follow Lunatic [0] as a candidate for future use, and also wasmCloud [1]. [0] https://lunatic.solutions/ https://lunatic.solutions/ [1] https://wasmcloud.com https://wasmcloud.com
- vilunov 3y agoI disagree with you in the last point, async is definitely painful for end users. It indeed feels like you're using a completely different language, which has Rust's core features removed – lifetimes and explicit types, sprinkled with a mess of Pins on top. You cannot run scoped fibers, forcing you to "Arc shit up", Pins are unusable without unsafe, and a tiniest change in an async-function could make the future !Send across the entire codebase.
- zamalek 3y agoIt may no longer be necessary for pins to exist for async implementation: https://doc.rust-lang.org/std/rc/struct.Rc.html#method.new_cyclic https://doc.rust-lang.org/std/rc/struct.Rc.html#method.new_c... (but the current async interface requires using them, so my point is definitely a whatifism).
- kprotty 3y agoReplacing Pin with Rc is what they refer to as "Arc shit up". Pin avoids the need for a heap allocation like Rc/Arc entirely.