Overall this article is accurate and well-researched. Thanks to Daroc Alden for due diligence. Here are a couple of minor corrections:
> When using an Io.Threaded instance, the async() function doesn't actually do anything asynchronously — it just runs the provided function right away.
While this is a legal implementation strategy, this is not what std.Io.Threaded does. By default, it will use a configurably sized thread pool to dispatch async tasks. It can, however, be statically initialized with init_single_threaded in which case it does have the behavior described in the article.
The only other issue I spotted is:
> For that use case, the Io interface provides a separate function, asyncConcurrent() that explicitly asks for the provided function to be run in parallel.
There was a brief moment where we had asyncConcurrent() but it has since been renamed more simply to concurrent().
Daroc here — I've gone ahead and applied two corrections to the article based on this comment. If you want to be sure that feedback or corrections reach us in the future (and not, as in this case, because I'm reading HN when I should be getting ready for bed), you're welcome to email lwn@lwn.net.
Thanks for the corrections, and for your work on Zig!
Hey Andrew, question for you about something the article litely touches on but doesn't really discuss further:
> If the programmer uses async() where they should have used asyncConcurrent(), that is a bug. Zig's new model does not (and cannot) prevent programmers from writing incorrect code, so there are still some subtleties to keep in mind when adapting existing Zig code to use the new interface.
What class of bug occurs if the wrong function is called? Is it "UB" depending on the IO model provided, a logic issue, or something else?
For example, the function is called immediately, rather than being run in a separate thread, causing it to block forever on accept(), because the connect() is after the call to async().
If concurrent() is used instead, the I/O implementation will spawn a new thread for the function, so that the accept() is handled by the new thread, or it will return error.ConcurrencyUnavailable.
What a really like about concurrent(), is that it improves readability and expressiveness, making it clear when writing and reading that "this code MUST run in parallel".
> > When using an Io.Threaded instance, the async() function doesn't actually do anything asynchronously — it just runs the provided function right away.
> [...]
Well, yeah, but even if you spin up a thread to run "the provided function right away" it still will only be for some value of "right away" that is not instantaneous. Creating a thread and getting it up and running is often an asynchronous operation -- it doesn't have to be, in that the OS can always simply transfer the caller's time quantum, on-CPU state, and priority to the new thread, taking the caller off the CPU if need be. APIs like POSIX just do not make that part of their semantics. Even if they did then the caller would be waiting to get back on CPU, so thread creation is fundamentally an async operation.
I can't imagine being someone like Andrew, or any BDFL of a popular open source project, and having to deal with folks like this. Imagine posting a timed output of your compiler on a thread about a similar language's slow compiler and having someone cite this as bad behavior.
Anyway, the clear absurdity of this particular post aside, it's not OK to call other people monkeys. I make no statement on the quality of their engineering. But they're people! I'd hope to see a quiet dignity from the Zig folks here. They've done so much excellent work, and I'm sure it's frustrating to see what software can be and then have it sharply laid against what software often is. But kindness is always the way.
Thanks to everyone involved with Zig for their work and love of software!
It's completely fine for someone working on a programming language that is useful for some of the same things as Rust to compare that language to Rust, including in ways that make the language not seem as good. Indeed, this is useful information for someone who is using Rust and is considering using Zig (or vice-versa), or who is new to both languages and trying to figure out which is better for their use case.
In what way is the tone of the linked messages not appropriate? Rust is a programming language, not a sacred object. It's fine to say that a different programming language does something better than it, regardless of whether or not you're the developer of that language.
To be clear I like Rust and use it frequently and have for about as long as it's been publicly released, whereas I have only played around a little bit with Zig and I suspect I won't like it as much as Rust even when it's feature-complete. But I don't like seeing an attempt to enforce a social norm that it's wrong to point out shortcomings of Rust, especially when it's aimed at people doing the interesting and valuable work of exploring other areas of the systems programming language design space that Rust is not doing.
In the vast majority of cases, cancellation will be handled transparently by virtue of `try` being commonly used. The thing that takes relatively longer to do is I/O operations, and those will now return error.Canceled when requested.
Polling cancelRequested is generally a bad idea since it introduces overhead, but you could do it to introduce cancellation points into long-running CPU tasks.
> Now that it's only using one thread, it deadlocks, because the consumer is waiting to get something from the queue, and the producer is scheduled to run, but it has not run yet.
Is the reason that the queue has a zero buffer size (always "full"), so that the consumer must consume the `flavor_text` before the producer can return?
Queue source:
> /// When buffer is full, producers suspend and are resumed by consumers.
This post was really good right up until the screenshot of ChatGPT... It would be a big improvement to convert that to HTML, fact check it, and then not cite LLM as a source.
The actual reason is that the vast majority of Duolingo users are only using the app because they like to play Duolingo. I don't say this to insult Duolingo users, but they're not actually serious language learners. They just really like playing Duolingo and if Duolingo stopped existing, they would simply stop "learning" languages all together.
It's flashcards++: They can have audio attached, for example, and multiple "sides" to the flashcard, but the most ++ part of it is the integrated spaced repetition algorithm(s) that automagically adapt the next time a card is shown based upon its difficulty to improve long-term recall without having to look at all of the cards super often. This is termed spaced repetition.
It's really good. It's still flash cards and best for things where you just have to memorize something (I use it for mandarin characters, for example, for which it's really excellent). But it's great at what it does.
because setting up and using anki is a pain? using and configuring anki is not intuitive. if you're just starting, you'll probably need to find a good premade vocab deck. once that's done, you'll need to make cards. making cards manually is a pita, i would probably not make any if i didn't have a good mining setup (yomitan/ttsu reader/asbplayer). i've spent countless hours getting my mining setup just right (setting up anki and yomitan, tweaking card fields/templates). yomitan probably works well because japanese conjugation is so regular. i imagine for languages with less regular conjugation, it wouldn't be so nice.
This is very related to a talk I did last year [1]. "Part 2: youtube-dl" starts at 18:21. It dips toes into an analysis about software that fundamentally depends on ongoing human labor to maintain (as compared to, e.g. zlib, which is effectively "done" for all intents and purposes).
More concretely, the additional Deno dependency is quite problematic for my music player, especially after I did all that work to get a static, embeddable CPython built [2].
Ideally for me, yt-dlp would be packaged into something trivially embeddable and sandboxable, such as WebAssembly, calling into external APIs for things like networking[3]. This would reduce the value delivered by the yt-dlp project into pure DRM-defeating computation, leaving concerns such as CLI/GUI to a separate group of maintainers. A different project could choose to fulfill those dependencies with Deno, or Rust, or as in my case, built directly into a music player in Zig.
Of course I don't expect the yt-dlp maintainers to do that. They're doing something for fun, for free, for pride, for self-respect... in any case their goals aren't exactly perfectly aligned with mine, so if I want to benefit from their much appreciated labor, I have to provide the computational environment that they depend on (CPython[4] and Deno).
But yeah, that's now going to be a huge pain in the ass because now I either have to drop support for yt-dlp in my music player, or additionally embed deno, as well as introduce Rust as a build dependency... neither of which I find acceptable. And don't even get me started on Docker.
> When using an Io.Threaded instance, the async() function doesn't actually do anything asynchronously — it just runs the provided function right away.
While this is a legal implementation strategy, this is not what std.Io.Threaded does. By default, it will use a configurably sized thread pool to dispatch async tasks. It can, however, be statically initialized with init_single_threaded in which case it does have the behavior described in the article.
The only other issue I spotted is:
> For that use case, the Io interface provides a separate function, asyncConcurrent() that explicitly asks for the provided function to be run in parallel.
There was a brief moment where we had asyncConcurrent() but it has since been renamed more simply to concurrent().