Comment by do_not_redeem

Comment by do_not_redeem a day ago

34 replies

View on Hacker News

I'm generally a fan of Zig, but it's a little sad seeing them go all in on green threads (aka fibers, aka stackful coroutines). Rust got rid of their Runtime trait (the rough equivalent of Zig's Io) before 1.0 because it performed badly. Languages and OS's have had to learn this lesson the hard way over and over again:

https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13...

> While fibers may have looked like an attractive approach to write scalable concurrent code in the 90s, the experience of using fibers, the advances in operating systems, hardware and compiler technology (stackless coroutines), made them no longer a recommended facility.

If they go through with this, Zig will probably top out at "only as fast as Go", instead of being a true performance competitor. I at least hope the old std.fs sticks around for cases where performance matters.

mlugg a day ago

I'm not sure how you got the perception that we're going "all in" on green threads, given that the article in OP explicitly mentions that we're hoping to have an implementation based on stackless coroutines, based on this Zig language proposal: https://github.com/ziglang/zig/issues/23446

Performance matters; we're not planning to forget that. If fibers turn out to have unacceptable performance characteristics, then they won't become a widely used implementation. Nothing discussed in this article precludes stackless coroutines from backing the "general purpose" `Io` implementation if that turns out to be the best approach.

Reply View 15 replies
  • ksec a day ago

    That is lovely to hear. I think the general conscious is that not a single programming language has done Async right. So people are a little sceptical. But Andrew and the team so far seems to have the do it right mentality. So I guess people should be a little more optimistic.

    Cant wait for 0.15 coming out soon.

    Reply View 3 replies
    • krior 21 hours ago

      I would argue that Java's async is pretty nifty, especially now that some of the rough edges have been sanded off.

      Reply View 0 replies
  • do_not_redeem a day ago

    Does the BDFL want this though, or is it just one person's opinion that it might be nice? Given how he has been aggressively pruning proposals, I don't put any hope in them anymore unless I see some kind of positive signal from him directly.

    e.g. I'd feel a lot more confident if he had made the coroutine language feature a hard dependency of the writergate refactor.

    Reply View 10 replies
    • kristoff_it a day ago

      mlugg is in the Zig core team

      Reply View 9 replies
      • do_not_redeem a day ago

        I'm aware, but Zig isn't a democracy where the core team votes, right? Has Andrew actually expressed that he wants the proposal? Without that we're left with scraps like this commit message where he seems ambivalent. https://github.com/ziglang/zig/commit/d6c90ceb04f8eda7c6b711...

        Andrew, I know you read these threads sometimes, give us a sign so I can go down the mountain with my stone tablets and tell the people whether we'll have coroutines

        Reply View 8 replies
nsm a day ago

I’m confused about the assertion that green threads perform badly. 3 of the top platforms for high concurrency servers use or plan to use green threads (Go, Erlang, Java). My understanding was that green threads have limitations with C FFI which is why lower level languages don’t use them (Rust). Rust may also have performance concerns since it has other constraints to deal with.

Reply View 6 replies
  • yxhuvud a day ago

    Green threads have issues with C FFI mostly due to not being able to preempt execution, when the C thing is doing something that blocks. This is a problem when you have one global pool of threads that execute everything. To get around it you essentially need to set up a dedicated thread pool to handle those c calls.

    Which may be fine - go doesn't let the user directly create thread pools directly but do create one under the hood for ffi interaction.

    Reply View 5 replies
    • layer8 19 hours ago

      The problem is when C calls expect to be on a particular thread. Either the main event thread, in a GUI context, or the same thread as some related previous call.

      Reply View 4 replies
      • ori_b 17 hours ago

        The problem is that C expects to have enough stack to put stuff there, but green threads allocate small stacks to reduce (virtual) memory use.

        Reply View 3 replies
andyferris a day ago

It actually has much the same benefits of Rust removing green threads and replacing them with a generic async runtime.

The point here is that "async stuff is IO stuff is async stuff". So rather than thinking of having pluggable async runtimes (tokio, etc) Zig is going with pluggable IO runtimes (which is kinda the equivalent of "which subset of libc do you want to use?").

But in both moves the idea is to remove the runtime out of the language and into userspace, while still providing a common pluggable interface so everyone shares some common ground.

Reply View 0 replies
dundarious a day ago

It's hardly "all-in" if it is merely one choice of many, and the choice is made in the executable not in the library code.

Reply View 6 replies
  • do_not_redeem a day ago

    I have definitely gotten the impression that green threads will be the favored implementation, from listening to core team members and hanging around the discord. Stackless coroutines don't even exist in the language currently.

    Reply View 5 replies
    • dundarious a day ago

      What does "favored" mean if event loop and direct blocking are relatively trivial and provided also/ If I can trivially use them, what do I care what Andrew or someone in core thinks? The control is all mine, and near zero cost (potential vtable indirection).

      And would Rust be "all-in" if tokio was in std, so you could use its tasks everywhere? That would be a very similar level of "all-in" to Zig's current plan, but with a seemingly better API.

      I understand the benefit of not being in std, but really not a fundamental issue, IMO.

      Reply View 0 replies
    • andyferris a day ago

      In the 2026 roadmap talk Andrew Kelley spoke of the fact that stackless coroutines with iouring is the end goal here (but the requires an orthogonal improvement in the compiler for inlining that data to the stack where possible).

      Reply View 1 reply
      • do_not_redeem a day ago

        Do you have the timestamp? I watched that video when it came out and don't remember hearing it.

        Reply View 0 replies
    • geodel a day ago

      > Stackless coroutines don't even exist in the language currently.

      And green thread exists in language?

      Reply View 1 reply
      • [removed] a day ago
        [deleted]
        Reply View 0 replies
flohofwoe a day ago

> I'm generally a fan of Zig, but it's a little sad seeing them go all in on green threads

Read the article, you can use whatever approach you want by writing an implementation for the IO interface, green threading is just one of them.

Reply View 0 replies
forrestthewoods 16 hours ago

Oh man. I think the biggest mistake Rust has ever made is their async model. It’s been nothing short of a disaster. Zig supporting green threads and other options is spectacularly exciting. Thus far no one has “solved” async. So very exciting to see what Zig can come up with.

Reply View 0 replies