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