Bun was not a good citizen in the Zig ecosystem. They had their own incompatible version of the language, you couldn’t use the official compiled to build their project. As far as I know, they have no open source libraries, all code was in their repo intended to be used internally. Whether they use their own “Zig” or Rust should make no difference to developers wanting to use Zig, no?
12 Likes
Should’ve LLM rewrite to V for those juicy compile times 
4 Likes
Sadly your post also feels like veiled Anthropic ad
It would be a nice ad, but at the same time, does it actually solve a problem?
I guess we’ll see. I bet a lot people are doing the same. But the point is, you can’t just dismiss it being just another ad
As far as I’m aware, correct me if I’m wrong, Bun has not sponsored Zig since the acquisition.
(edit: i quoted the wrong thing, sorry, meant to quote the corporate sponsor post)
3 Likes
Correct, Bun has stopped donating after the acquisition.
To give my 2c more in general, I think here we have the opportunity of observing how good are the claims about AI and Rust by observing how Bun fares going forward. People have judged Zig for bugs in Bun’s codebase and now we can finally see how valid are those claims, if Oven decides to commit to the rewrite.
23 Likes
My thoughts went to the end of Burn After Reading.
2 Likes
It would have been interesting though to see if std.Io was enough to implement a JS runtime on top of it.
1 Like
All JS runtimes I know use callback-based event loop behind the scenes. I don’t think std.Io (a blocking API) is a good fit for this.
1 Like
They did donate a lot of money to zsf to help improve zig. having a fork of the compiler does not make them a bad citizen. Zig is where it is today thanks to all the people that donate to allow the core team improve the language and tool chain. it’s also okay that zig no longer meets their needs and they are moving on. That’s just life.
8 Likes
std.Io.Uring for instance being called a blocking API is a little confusing to me! can you elaborate?
The public API is blocking, for example, when you request to receive data from network, you call a function and it blocks until data is received. The fact that std.Io.Evented used an event loop inside is irrelevant, because that’s not accessible to the user. From the user’s perspective it’s the same as sending a recvmsg syscall. Only std.Io.Batch could be considered async/non-blocking API. Non-blocking APIs either query for completed events (iouring/kqueue/iocp) or use callbacks (libuv/libxev/iocp).
not related exactly to io_uring, but bun uses single-threaded reactor model , is not supported by current Io
But they don’t have to write in human language, as that is also gutting them down. Which is why I said they could use their own bytecode, that only the LLM understands.
1 Like
ohhhh i see. so what i hear you saying is “Zig’s async/await appears blocking to the user and other event loops do not appear blocking to the user, this is a problem”. is that right?
Yes. That’s the problem if you need to implement async/await with networking for JavaScript. You need a lower level API for that. 
i don’t understand why, could you explain more?
if more context about me is useful, i recently implemented a toy version of async/await for Lua with std.Io and didn’t run into any showstoppers, despite the “high level” of the API
2 Likes
I’m not going to pretend I know much about JS runtimes, but JS APIs are historically event based and therefore you would have to expensive translation layer from the blocking calls, wasting a lot of threads/coroutines for something that can be event-based all the way to the OS.
as far as i understand js engine of bun runs of single-threaded event loop supported by vendored version of usockets
interesting! it sounds to me like you’re making very strong claims without a lot of experience to back it up.
from my perspective so far, since JavaScript’s async/await semantics involves the (implicit) idea of a suspension point, it’s pretty easy to write the Zig code up to the suspension point in Zig and make that the suspension point for—in my case Lua, and then write the resuming code as the resuming code.
I’ll have to let you know if I waste a lot of coroutines
I view it a little differently. If you are trying to maintain a large project written in pre-1.0 language where you know there is going to be churn, it doesn’t seem unreasonable to try to insulate yourself a little bit.
I believe the whole thing is already open source. Could the Bun team have done more? Sure, but IIRC, before they got acquired by Anthropic, it was a small/solo endeavor, so I wouldn’t expect them to be spending all their time writing blog posts, giving talks, documenting and publishing internal libraries, or anything like that.
I think the counter argument is that it’s good for Zig adoption to be able to point to this well known project.
4 Likes