Rust

5969 readers

25 users here now

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

Wormhole

[email protected]

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

Async Rust Is A Bad Language (bitbashing.io)

submitted 1 year ago by fil to c/rust

24 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] BB_C 23 points 1 year ago* (last edited 1 year ago) (1 children)

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

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!

[–] BatmanAoD 1 points 1 year ago (1 children)

I think the point of the "BIG_GLOBAL_STATIC..." name is that global statics are bad, not that the syntax is ugly. That said, you're absolutely correct that combining channels with async code is the way to go.

[–] BB_C 0 points 1 year ago

I think the point of the “BIG_GLOBAL_STATIC…” name is that global statics are bad, not that the syntax is ugly.

Yes. And my point was that there is an obvious way of sharing data besides passing static-refs, cloning, and using Arcs, which is moving data bidirectionally. That was conveniently, or ignorantly, glossed over by the coping gopher.