I work on Bun. Happy to answer questions
Having recently started coding in Zig, in no small part because of Bun, I would like to know: How do you deal with the fact that Zig is not a very stable language yet? I was surprised to find out that Andrew Kelley and his collaborators still consider breaking changes on a regular basis, that there quite a few bugs and, let's call them, unintentional inconveniences that will require further breaking changes to fix.
More generally, how do you like Zig?
The tension is understandable: Zig is explicitly not production-ready, yet it has such attractive performance and productivity properties, and has even proven useful in production scenarios (Bun, Uber, Tigerbeetle). But Andrew's suggestion is correctly aligned with Zig's mission and current level of maturity. If you have a complex project with lots of users like Jarred does, stick with a tagged release for now.
The highest priority of Zig pre-1.0 is to make the language the best it can be — which it will be in due time. The target audience of the master branch is those who can withstand churn and are focused on getting it there.
Best way to use typescript and have things “just work” as compared to node and node-ts and setting type:”module” in package.json and dealing with headaches.
Some things to add: - duckbd embedded like sqlite - fix the stdout/stdin terminal issues so it can be used for fast CLI stuff (basic things like columns/rows count, rawMode, mouse, et all) - sub project to port electron apis so we can have a new, mostly compatible version of electron that uses bun for the headless processing and uses system webviews for front lens (no node integration).
IMO (not strongly held, largely as a spectator so far), it’s probably a bad thing in the long run for Bun (and Deno, and other JS server/CLI runtimes) to be so beholden to Node compatibility. I’d much rather see these compatibility efforts devoted to isolating Node-specific considerations, with clear guidance on how to migrate existing projects to more portable APIs. Node has already shown positive signs of embracing portability as contenders have also done. In the short term “works with stuff written for Node” is very appealing, but in the long term “Node works for stuff written for standards” is much more appealing than that. The more each of these runtimes courts the former, the more the latter is protracted.
require("stream").Readable require("stream/web").ReadableStream
I was using node-fetch and fastify but I decided to remove node-fetch to just use global.fetch and everything broke.
Turns out node-fetch and fastify uses require("stream").ReadableStream, but global.fetch() uses require("stream/web").ReadableStream (because it is a web standard). Took me a few hours to figure out why it wasn't working, getting some "ReadableStream is not a ReadableStream" error is very fun to troubleshoot
I don't know what approach Bun should take in this regard, but I would like to see NodeJS deprecating non-standards as much as possible so eventually this problem can go away. ECMA should also standardise things required for server-side code more
If you use glibc-compat, you can download Bun from the github releases and that should just work. In a docker image it's about 200 MB (bun's binary is around 90 MB right now, which is way too big imo)
This made me curious, so I checked out bun's repo and it's 217k lines of Zig (ignoring the other languages). Can you share what Zig's build times are like for a project that size?