Hacker News Reader

Comment by lukaslalinsky | Hacker News Reader

I've spent the last year working on an async runtime for Zig and I really grew fond of stackful coroutines. Your just program your code as if everything was blocking. The main benefit is that you can use whatever library, it doesn't have to be async aware. Heck, I could even use C libraries, and they would work correctly with my coroutines. I really don't understand why GC-based languages decided to go with stackless coroutines, given that they could do what Go is doing.

View on HN

> I really don't understand why GC-based languages decided to go with stackless coroutines

From what I've read it's due to a general idea that stacks use a lot of memory, which limits how many of them can be spawned. It's only good if it scales to a million concurrent users. A million 16 KiB stacks is over 16 GiB.

But if you have stack growth, the way Go does it, then the stack you allocate is actual memory you use. You are just trading heap allocations for stack growth. I started to see the stack as a super fast allocator that is always available.

Indeed. I think stacks are pretty great myself. Even the memory usage example I gave, which is the typical argument towards stackless, evaporates when the stacks are small. I benchmarked typical stack frames in my language at around 100-300 bytes. Chatting with Erlang/BEAM folks also revealed their stacks were in the same order of magnitude.

I think the popularity of event loops stems from the fact Node does it. Pretty much cooperative multitasking by another name. Functions are coroutines, return is yield and the event loop is the scheduler.

What are your thoughts on the Io situation? Has your work been with the Io plans in mind from the beginning?

My work was kind of similar to the `std.Io` plans, so when I learned about it, I started aligning the project to that interface. Now it's a full fledged implementation of the interface. It's actually the first async implementation of the interface, the one in stdlib is very far from finished.

There are many shortcomings in the API, especially missing timeouts everywhere. It was clearly designed by people working on the compiler and other local tools, and not much network services, but I think it's a great improvement in the Zig ecosystem and hopefully people can now write reusable libraries.

Reply on news.ycombinator.com