←back to thread

Asynchrony is not concurrency

(kristoff.it)
289 points kristoff_it | 5 comments | 18 Jul 25 19:21 UTC | HN request time: 0.001s | source
Show context
Retr0id ◴[18 Jul 25 20:08 UTC] No.44609223[source]▶
I don't get it - the "problem" with the client/server example in particular (which seems pivotal in the explanation). But I am also unfamiliar with zig, maybe that's a prerequisite. (I am however familiar with async, concurrency, and parallelism)
replies(2): >>44609353 #>>44609377 #
koakuma-chan ◴[18 Jul 25 20:20 UTC] No.44609353[source]▶
Example 1

You can write to one file, wait, and then write to the second file.

Concurrency not required.

Example 2

You can NOT do Server.accept, wait, and then do Client.connect, because Server.accept would block forever.

Concurrency required.

replies(2): >>44609387 #>>44610335 #
tines ◴[18 Jul 25 20:23 UTC] No.44609387[source]▶
Oh, I see. The article is saying that async is required. I thought it was saying that parallelism is required. The way it's written makes it seem like there's a problem with the code sample, not that the code sample is correct.
replies(1): >>44609503 #
Retr0id ◴[18 Jul 25 20:32 UTC] No.44609503{3}[source]▶
The article later says (about the server/client example)

> Unfortunately this code doesn’t express this requirement [of concurrency], which is why I called it a programming error

I gather that this is a quirk of the way async works in zig, because it would be correct in all the async runtimes I'm familiar with (e.g. python, js, golang).

My existing mental model is that "async" is just a syntactic tool to express concurrent programs. I think I'll have to learn more about how async works in zig.

replies(1): >>44609598 #
1. sunshowers ◴[18 Jul 25 20:41 UTC] No.44609598{4}[source]▶
I think a key distinction is that in many application-level languages, each thing you await exists autonomously and keeps doing things in the background whether you await it or not. In system-level languages like Rust (and presumably Zig) the things you await are generally passive, and only make forward progress if the caller awaits them.

This is an artifact of wanting to write async code in environments where "threads" and "malloc" aren't meaningful concepts.

Rust does have a notion of autonomous existence: tasks.

replies(3): >>44609714 #>>44609921 #>>44610390 #
2. Retr0id ◴[18 Jul 25 20:53 UTC] No.44609714[source]▶
Thanks, this clears things up for me.

I suppose I conflated "asynchrony" (as defined in the article) and "async" as a syntax feature in languages I'm familiar with.

3. m11a ◴[18 Jul 25 21:16 UTC] No.44609921[source]▶
I think that notion is very specific to Rust's design.

Golang for example doesn't have that trait, where the user (or their runtime) must drive a future towards completion by polling.

replies(1): >>44610103 #
4. sunshowers ◴[18 Jul 25 21:37 UTC] No.44610103[source]▶
Right, but Go is an application-level language and doesn't target environments where threads aren't a meaningful concept. It's more an artifact of wanting to target embedded environments than something specific to Rust.
5. jayd16 ◴[18 Jul 25 22:18 UTC] No.44610390[source]▶
Thank you so much for the added context. This explains the article very well.