21–30 of 305 posts
It was heavily discussed previously. In particular, it triggered this response from Rust contributor withoutboats: https://news.ycombinator.com/item?id=26410487 And this blog post from someone who did spend a lot of time working with async rust: https://tomaka.medium.com/a-look-back-at-asynchronous-rust-d...
The article glosses over async Rust and is mostly a rant about how closures are difficult in Rust. Most of the difficulty comes from Rust not having a GC yet wishing to keep track of object lifetimes precisely: a GC'ed language needs no distinction between an ordinary function pointer and a closure that captures the environment. But Rust being a low-level systems language chose not to have a GC. Another popular langu…
Does Rc help this much with async as well?
In summary asynchronous programming without a GC is a pain in the a*. That's somewhat expected isn't it?
It’s a pain with GC as well, coming from a C# background. It’s incredibly easy to write something that intermittently doesn’t work in weird and impossible to debug ways.
Async is bread and butter of JS and you rarely have any larger bits of sync code, so you learn to deal with this.
And then being able to just freely pass bits of data accessing code (closures) around is such wonderful feeling that you'll miss it everywhere else you go.
I recently had a little excursion into Python and had to invent a very nasty hack to concisely keep short bits of code accessible through some constants.
Excellent post. Async ruins everything even in GC languages. It's just making things needlessly hard for programmers in an attempt to save effort from computers. Erlang shows how to do massive scales of slow IO if you really need it (most programs don't).
Hold on now. Even in GC’ed languages? Which ones? It is another programming paradigm. It has its uses. It has its drawbacks. “Ruining everything” is a big stretch.
Excellent post. Async ruins everything even in GC languages. It's just making things needlessly hard for programmers in an attempt to save effort from computers. Erlang shows how to do massive scales of slow IO if you really need it (most programs don't).
Hold on now. Even in GC’ed languages? Which ones? It is another programming paradigm. It has its uses. It has its drawbacks. “Ruining everything” is a big stretch.
The issue of coroutine-based async is that a coroutine does not do anything until it's awaited (and the chain goes up to the reactor), so in Python when you create a coroutine nothing happens. This is unlike Javascript or C# (IIRC) where the baseline awaitable is a task, with tasks awaiting is a synchronisation point, but if you create a task and drop it the task will go and do its own thing.
In Rust, this is mitigated by `[must_use]`, so the compiler will warn you when you've created a coroutine (Future) and dropped it on the floor, not so Python, you just get a warning when the runtime shuts down, it's way harder to track missing awaits.
And the complaint is that Rust semantics makes this hard. Well yes, Rust makes it uncomfortable to shoot your own foot, that’s kind of the point.
The article glosses over async Rust and is mostly a rant about how closures are difficult in Rust. Most of the difficulty comes from Rust not having a GC yet wishing to keep track of object lifetimes precisely: a GC'ed language needs no distinction between an ordinary function pointer and a closure that captures the environment. But Rust being a low-level systems language chose not to have a GC. Another popular langu…
From my very limited expeirience with Rust I noticed that it becomes way more easy and laid back language when you just skip using references and lifetimes nearly completely and just wrap everything in Rc . Then you are getting expeirience of fairly high level language with a lot of very cool constructs and features like exhaustive pattern matching and value types with a lot of auto-derived functionality. Does Rc hel…
Using callbacks in Rust is not idiomatic, at least I haven't seen such code over the last two years writing Rust, and Rust syntax and semantics with life times is not tailored toward that approach.
So the author forces an async style on Rust that it was not build for and then complaints.
Excellent post. Async ruins everything even in GC languages. It's just making things needlessly hard for programmers in an attempt to save effort from computers. Erlang shows how to do massive scales of slow IO if you really need it (most programs don't).
> It's just making things needlessly hard for programmers in an attempt to save effort from computers. Well actually it is supposed to make concurrency easier for programmers. What would you say is an "easy" way to deal with concurrency? Handle threading, memory visibility issues, locking, etc yourself? Doing it "reactive"? I guess personally I too would say something messaging based such as the actor pattern but not…
The Beam/Erlang/Elixir model. It's a bit more constraining but it's just so clean and reliable, and processes having individual mailboxes makes it much simpler than having to wonder what synchronisation primitives to use, then decide how to share them (globals? parameters? others?).
Just get a reference to a process and you can send it messages, simple. If you want replies, send it your address. Also simple. And matches the real world very, very well (at least the real world of a few years back when you'd send letters through the mail, electronic communication channels tend to be more full-duplex).
Guess I'll just go back to erlang.....