6 ms·

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 tr

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/p1364r0.pdf 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.

dundarious 1y 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.
- do_not_redeem 1y 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.
  - andyferris 1y 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).
    - do_not_redeem 1y ago
      Do you have the timestamp? I watched that video when it came out and don't remember hearing it.
  - dundarious 1y 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.
  - geodel 1y ago
    > Stackless coroutines don't even exist in the language currently. And green thread exists in language?
    - deleted 1y ago
      [deleted]
andyferris 1y 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.
mlugg 1y 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 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.
- do_not_redeem 1y 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.
  - kristoff_it 1y ago
    mlugg is in the Zig core team
    - do_not_redeem 1y 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/d6c90ceb04f8eda7c6b71179ef2bdda92db9610f 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
      - kristoff_it 1y ago
        we do build internal consensus before publishing articles like this one, or doing other public communication.
nsm 1y 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.
- yxhuvud 1y 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.
  - layer8 1y 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.
    - ori_b 1y 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.
      - layer8 1y ago
        That’s not a problem when a dedicated thread pool is used as mentioned by GP. However they don’t solve the thread affinity issue.
        ori_b 1y ago
        That's the reason for the thread pool, and the resulting thread affinity issue.
flohofwoe 1y 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.
oasisaimlessly 1y ago
That paper (P1364R0) was contentious, and I regard it as being severely motivated reasoning, published only to kill off competing approaches to C++ coroutines. Some discussions of that paper: * https://old.reddit.com/r/cpp/comments/1jwlur9/stackful_coroutines_faster_than_stackless/ https://old.reddit.com/r/cpp/comments/1jwlur9/stackful_corou... * https://old.reddit.com/r/programming/comments/dgfxde/fibers_arent_useful_for_much_any_more/f3bmpww/ https://old.reddit.com/r/programming/comments/dgfxde/fibers_...
forrestthewoods 1y 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.

dundarious 1y 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.

do_not_redeem 1y 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.
- andyferris 1y 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).
  - do_not_redeem 1y ago
    Do you have the timestamp? I watched that video when it came out and don't remember hearing it.
- dundarious 1y 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.
- geodel 1y ago
  > Stackless coroutines don't even exist in the language currently. And green thread exists in language?
  - deleted 1y ago
    [deleted]

andyferris 1y 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.

mlugg 1y 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 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.

do_not_redeem 1y 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.
- kristoff_it 1y ago
  mlugg is in the Zig core team
  - do_not_redeem 1y 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/d6c90ceb04f8eda7c6b71179ef2bdda92db9610f 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
    - kristoff_it 1y ago
      we do build internal consensus before publishing articles like this one, or doing other public communication.

nsm 1y 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.

yxhuvud 1y 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.
- layer8 1y 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.
  - ori_b 1y 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.
    - layer8 1y ago
      That’s not a problem when a dedicated thread pool is used as mentioned by GP. However they don’t solve the thread affinity issue.
      - ori_b 1y ago
        That's the reason for the thread pool, and the resulting thread affinity issue.

flohofwoe 1y 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.

oasisaimlessly 1y ago

That paper (P1364R0) was contentious, and I regard it as being severely motivated reasoning, published only to kill off competing approaches to C++ coroutines. Some discussions of that paper: * https://old.reddit.com/r/cpp/comments/1jwlur9/stackful_coroutines_faster_than_stackless/ https://old.reddit.com/r/cpp/comments/1jwlur9/stackful_corou... * https://old.reddit.com/r/programming/comments/dgfxde/fibers_arent_useful_for_much_any_more/f3bmpww/ https://old.reddit.com/r/programming/comments/dgfxde/fibers_...

forrestthewoods 1y 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.