- cross-posted to:
- rust@lemmy.ml
- rustlang@lemmyrs.org
- cross-posted to:
- rust@lemmy.ml
- rustlang@lemmyrs.org
fn foo(&big, &chungus)
is out,
async fn foo(&BIG_GLOBAL_STATIC_REF_OR_SIMILAR_HORROR, sendable_chungus.clone())
is in.
Or maybe you know
fn foo(&big, &chungus)
is out
async fn foo(big, chungus) -> (big, chungus)
is in
Or
async fn foo(big, chungus) { // ... tx.send((big, chungus)).await?; // ... }
is in
Moving (movable/sendable) data is not limited by number or direction, you know. And that second one even makes use of them great Hoare channels! And gives us control on how long we hold on to data before sending it back (modified or not). But I digress. Let’s go back to the important talking point that Hoare was right!
Async rust might suck, compared to async in higher level languages, but for someone comming from C, async rust simplifies a lot of stuff. It often feels like a lot of criticisms of rust boils down to the fact that rist was sold to both people using low and high level languages. I don’t doubt that async rust is shit when all you want is a faster typescript.
Edit: I certainly also have my criticisms of rust and its async implementation, and I think some of the authors concerns are valid, it was just an observation about the tension between the needs of the two groups of users.
Maybe it’s just me, but isn’t async programming a mess in all programming languages?
Zig’s approach seems even more low-level and manual: https://ziglearn.org/chapter-5/
(In general, I think Rust and Zig both seem valuable, and I think it’s a mistake to treat programming language success as a zero-sum game.)