What I learned about Bun&ZIg

Explain
, ,
1

This post is the result of two independent events:

The post above contains a lot of information about Rust and almost nothing about Bun & Zig.

But Bun is a very interesting project, and knowledge regarding its use of Zig may help us.

Bun uses Zig as “better C” - modern low-level language with excelent coordination with existing “battle-tested” C code (not libs), custom allocators.

Bun minimized usage of Zig std, as less stable part of Zig.

Not related to stability - it’s impossible using current Io implement what bun did using vendored C based usockets.

And funny fact - bun uses Claude code, at least System Calls & File I/O in Zig (it’s human created text - don’t warry) contains following sad rules

Use bun.sys instead of std.fs or std.posix for cross-platform syscalls with proper error handling…Prefer bun.sys.File wrapper for most file operations…For sockets, use uws.Socket not bun.sys

2 Likes
Zadness re bun
Quick, everyone sh*t on Io!
2

22 posts were merged into an existing topic: Should the standard library be “batteries included”?

11

don’t expect
it was the reason

Actual problem raised in this discussion - Io implementation forced developers to invent own “posix”…

1 Like
16

Can we change that?

I recently implemented a low latency server and I had to ditch the kernel cause it adds >100us of overhead to each packet.

I’ve a hard time imaging std.Io is that slow compared to Linux. But in any case the API doesn’t lend itself to wrap a Dpdk like API.

Basically the DPDK API is to preallocate buffers mapped by the NIC. Then you ask the IO to give you buffer to write packets, then you can flush several packets at once. To receive packets, the IO interface give you the packets in its own buffers, so you need to explicitly release them, or reuse them for sending.

Each buffer is like an ArrayList where headers are typically stored between the data.

18

My biggest worry from this thread is that you’re just going to turn around and say “all my remarks were based on the AI thread that was removed that you didn’t read. Gotcha!”

I’d like to engage, as I do have some thoughts on Bun and Rust, but I do not trust that I’m engaging with someone in good faith.

3 Likes
19

I got your point, but i’d like to answer public

I am working some weeks in order to migrate my zig posix based project to zig 0.16.+ , this migration is based on bun’s way: Zig - high level , C - low level

I posted several posts and raised attention to what happened in zig with new Io

Don’t worry - I learned bun zig/c cooexistance very deeply and my remarks reflect the real status

Simply skeep what I wrote and read the rest

btw we are talking about Bun&Zig

1 Like
20

Opened new thread New Io and low-level programming

21

Getting a Page Not Found error with that link

22

it was removed “as spam” :joy:
not guilty

1 Like
25

Actually if you are developing something heavily on system levels, it is completely okay to use or call some system level libraries, which are most likely written in C… It is completely okay… Zig stdlib is just one of those implementations for some tasks, and it’s new. I believe that it will become better, and it will become one of the most appropriate solutions for many people. I trust the community and the team and also Andrew that they will do it better.

At the meantime, if you cannot find a good solution, it’s okay to deal with it on your own ways. It’s absolutely normal to call whatever C libs, especially on system levels.

Imagine if you want to develop a Zig windowing system for Linux, most likely you will call libwayland-client or xlib… Then if you want to use your windowing system to do some 3D things, you may also need vulkan.h… Then you want to add some sounds, you probably go with ALSA or even pulseaudio or even pipewire, or even WirePlumber… A programming language’s stdlib is not a magic wand to solve every problems. You always encounter a lot of binding and wrapping. Even in Rust, Go, Odin, there are tons of crates, libs, packages are based on some sorts of lower level binding or wrapping.

And if you want something on even lower levels, like a micro controller, router, or whatever device, or even developing your own operating system, then you don’t go with stblib either… even if you are writing in C…

Again, I trust the community will make the things better, and also wish and trust everyone here will find your best solutions for your projects.

3 Likes
27

Most low-level bindings - part of Odin’s distribution

Its use is similar to that of core: packages, which would be available in any Odin implementation.

Odin’s “Io” is based on Odin’s “posix”

32

I’ve personally been quite happy with many of the std’s offering. In age of internet having crypto, TLS, http (server/client) straight in std is quite handy indeed. Considering how common place supply-chain attacks are becoming and how zig compiles only the things you reference, I’d not be too unhappy seeing batteries included std and bigger decentralized third-party deps in general.

9 Likes
33

I think Zig is an ecosystem, more than just a programming language. I’m not sure if Bun will migrate from Zig or not, that is their decision and I wish them all luck.
What I do care about is the continuation of the ecosystem. “What I learned about Bun & Zig” is that the ecosystem is going strong, without having the pressure from Anthropic or corporate to ruin something that many is working hard on it.
Software has this magic of reaching and effecting the lives of many because it scales, and I am tired of recent (more like a decade?) deterioration of software quality because big companies has no real competition, and in the corporate world, the most used design pattern is Disaster Driven Development. Perhaps that’s why Go is good for many things that keeps it simple and straight forward.

I’m not saying Rust is bad. The Rust ecosystem has its momentum going strong, and I respect the minds and the thought process behind it. The same goes to Zig. It has its own mindset and I love the community and the team that is working tirelessly to achieve a vision. It is a thankless job and I wish them the best.

A question that the Bun team has to answer now: Why Bun? If Rust is your new butter, I think Deno already did that, and I don’t think JSC is a real differentiator at this point. It is just Sequoia vs Anthropic.

6 Likes
35

if you’re so frustrated with the slow pace of change, send a PR about the issue you want fixed.

Keep in mind: Please do not file a proposal to change the language

1 Like
36

Since Zig is designed to be able to be used without the standard library, I wonder if there’s a future where we might see sub-ecosystems or distributions. E.g. a handful of developers write their own standard library and build other libraries and utils on top of it.

1 Like
37

I think microzig is an example for this

38

That would prove the ‘Zen’ part of Zig. A standard library (from my understanding) will end up having abstraction over an OS. That might be a good starting point for most needs.

I’m excited to see what would be the thought processes that the team will end to use and define what belongs in the standard library and to what degree it abstracts concepts.
Go team decided to provide a heavy battery-included standard library and it is of high quality, with the assumption that it is within the realms of Go.
Rust by nature needs a standard library to provide ‘primitives’. The problem is the standard library cannot be replicated 100% as it has its own cheat code that is not available to others. Zig does not have that problem.

2 Likes
39

I believe that in modern day and age, a language’s std should focus on providing the foundation and lego brick from which everything in the ecosystem can stem, for example the last thing I want is for something as fundamental has Allocators to not be part of the std, because then the entire ecosystem is split into those that use allocators, those that don’t, those that use that particular library but not that one etc.

Same with Async honestly having Io as an interface is amazing, I’ve experienced first hand the pain of seeing the perfect dependency for your project, yet you can’t actually use it because you can’t schedule it’s work to fit your constraint, Io opens an entire universe of code reuse that just wasn’t available before.

The next thing I don’t ever want to have to reach for are data structure, at least the basic one, because again Data structure are kind of the linguo and the most basic interfaces, there’s nothing more disgraceful than using 3 libraries and all of them have a different ArrayList.

So I’m personally all for a broad battery included std, and right now I can’t say it’s missing much. One model that I’d love Zig to follow with the std, is the model of OpenCV, where you have the core, and the contrib, where contrib is kind of the 2 class “std”. I think this is a great way to maintain a simpler cohesive ecosystem and avoid people reinventing the wheel too much, and promotes code reuse.

For example it wouldn’t make sense for Zig to have a dedicated 2d or 3d math namespace in the std, it’s a huge burden on maintainers because of the sheer amount of api, and ways one can design them.

At the same time many libraries realistically need good 2d/3d, and developers would most certainly love not to have to deal with 3 different implementation of a vector or matrix, when trying to reuse those libraries. Same with TUI or Yaml parsing..

I think having a 1st class std of curated, high impact, high ROI building blocks is crucial for a healthy ecosystem and an enjoyable experience, But if on top of that ZFS could decide to “promote” one very popular high impact library has part of the std-contrib that would be a nice way to make it easy and safe for people to get the battery included, plus the charging cable, and the nuclear reactor, it promotes code reuse, and reduce the attack surface, focus the collective effort, into an official but not maintained as much or with the same guarantees as the core std.

2 Likes
40

I think I saw someone comment how the std should only include what the compiler developers need. A CRAZY ong term idea. BUT pre-1.0 not creating a huge std code base that has to be fix,reconfigured, reorganized, and optimized every time there is a new breaking change makes complete sense. AFTER 1.0 yeah grow a strong std be a perfect function workbench to start from.