←back to thread

Async/Await is finally back in Zig

(charlesfonseca.substack.com)
39 points barddoo | 2 comments | | HN request time: 0s | source
Show context
ajross ◴[] No.45782414[source]
Is it time now to say that async was a mistake, a-la C++ exceptions? The recent futurelock discussion[1] more or less solidified for me that this is all just a mess. Not just that one bug, but the coloring issue mentioned in the blog post (basically async "infects" project code requiring that you end up porting or duplicating almost everything -- this is especially true in Python). The general cognitive load of debugging inside out code is likewise really high, even if the top-level expression of the loop generator or whatever is clean.

And it's all for, what? A little memory for thread stacks (most of which ends up being a wash because of all the async contexts being tossed around anyway -- those are still stacks and still big!)? Some top-end performance for people chasing C10k numbers in a world that has scaled into datacenters for a decade anyway?

Not worth it. IMHO it's time to put this to bed.

[1] No one in that thread or post has a good summary, but it's "Rust futures consume wakeup events from fair locks that only emit one event, so can deadlock if they aren't currently being selected and will end up waiting for some other event before doing so."

replies(5): >>45782432 #>>45782502 #>>45782558 #>>45782647 #>>45782786 #
the__alchemist ◴[] No.45782558[source]
Concur. I build my own tools in rust when I have to just to avoid it. It is splitting rust into 2 ecosystems, and I wish it didn't exist because it's a big compatibility barrier. We should be moving towards fewer of these; not more. Make code and applications easier to interop; Async makes it more difficult.
replies(1): >>45782624 #
1. echelon ◴[] No.45782624[source]
I can't stand this aversion to async/await. It's not a big deal.

I don't understand why async code is being treated as dangerous or as rocket science. You still maintain complete control, and it's straightforward.

Now that we know about the "futurelock" issue, it will be addressed.

I'm sure Rust and the cargo/crates ecosystem will even grow the ability to mark crates as using async so if you really care to avoid them in your search or blow up at compile time upon import, you can. I've been asking for that feature for unsafe code and transitive dependency depth limits.

replies(1): >>45783875 #
2. jeltz ◴[] No.45783875[source]
Because async Rust is a lot harder to reason about than sync code. And I want my code to be as easy to reason about as possible.