this post was submitted on 08 Sep 2023
1 points (100.0% liked)

Rust

5931 readers
8 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
top 9 comments
sorted by: hot top controversial new old
[–] BB_C@programming.dev 2 points 1 year ago* (last edited 1 year ago)

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!

[–] pileghoff@programming.dev 2 points 1 year ago* (last edited 1 year ago)

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.

[–] wim@lemmy.sdf.org 2 points 1 year ago (1 children)

Maybe it's just me, but isn't async programming a mess in all programming languages?

[–] noli@programming.dev -1 points 1 year ago (2 children)

It's a joy to do async in go IMO

[–] wim@lemmy.sdf.org 1 points 1 year ago

That's a whole different thing to me. That's not async, that's channels and multithreading.

I do that in Rust as well with mcsp channels and it's been fine.

It's the async/await bit that I find incredibly akward all the time.

[–] vrighter@discuss.tchncs.de 0 points 1 year ago* (last edited 1 year ago)

not really. first of all async in not the same as threading. And even then, while it makes parallel code easier to write (not easier to reason about), it still has the exact same footguns as anything else, as soon as you venture away from having only one consumer for every producer. Synchronization is still all on you

[–] SorteKanin@feddit.dk 1 points 1 year ago* (last edited 1 year ago)

Interesting read but I don't agree that it's as bad as the author makes it sound. I'm also curious what an alternative would be, if you don't want a garbage collector?

In my personal experience, you don't run into all the Arc, Pin and 'static stuff that often. I would even say very rarely.

[–] Cyberflunk@lemmy.world 0 points 1 year ago (1 children)
[–] BatmanAoD@programming.dev 1 points 1 year ago

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.)