Bun v0.5.7
bun.sh
bun.sh
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.
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?
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).
I have a CLI ghat does some processing and Bun used all the memory and pushed me deep into swap on a 64gb ram machine. I added some Bun.sleep(1) in the some loops to give the GC more time but that didn’t help much.
For now, try doing Bun.gc() and if that doesn’t help enough, try Bun.gc(true). This isn’t a great solution because it will make your code slower
The GC schedules automatically on event loop tasks and in a few other points in the lifecycle of the application. It is not yet scheduling under memory pressure events and I think that’s what’s missing here
From the docs [1], "Bun is an all-in-one toolkit for JavaScript and TypeScript apps. It ships as a single executable called bun ."
"Bun is a fast all-in-one JavaScript runtime"
% bun test bun test v0.5.7 (5929daee)
17 | expect([...] ^ error: Not implemented
error: Unexpected ? ?PNG ^ [...]/a.png:1:1 0
zsh: segmentation fault bun test
It looks like some code is importing a .png file and then some other issue (likely related to that) is causing a crash in the test runner
Can you file an issue on https://github.com/oven-sh/bun/issues/new?assignees=&labels=... with sample code reproducing it? Happy to take a look
We are working on a rewrite of the bundler. The current implementation only bundles node_modules (meaning it doesn’t behave like esbuild —bundle), doesn’t correctly handle a number of cases with ESM <> CJS interop, and doesn’t produce compact or optimized output. Fixing this is one of the top priorities right now.
Jarred previously mentioned it was worth a look: https://news.ycombinator.com/item?id=34431432
However, I've discovered Vite since then, and I know it's not a 1:1 comparison, but Vite is much more mature, and does everything I need and is incredibly user friendly and plenty fast enough for me. I kinda feel like Bun missed its moment already. Someone convince me otherwise please. I'm loving Vite it's a huge step up from Webpack, and isn't leaving me wanting for anything more.
And following up on that, has anyone tried a Bun/Vite combo?
While I'm not particularly into or even all that interested in Bun, this pop culture attitude in general always mystifies me. What's the purpose of adopting this attitude (or is it involuntary)?
Even if Vite were to do exactly what Bun does, they could both still exist and the world would just move along as it did before. Something being popular or not doesn't matter if it solves something.
I imagine people who have this attitude turn into people who never actually try out anything for fear of using something that less than 5% of developers use. Most actually good things I know are used by far less than even that and they solve real problems for me.
P.S. I would argue popularity hasn't helped JavaScript one bit: it's barely improving at all and most of the ecosystem is still a massive pain to use, most of the libraries are awful, performance is still lacking and basics like threading are still not solved. The popularity only helps with getting people into the churn and that's a dubious goal at best. Most of these points apply to Python as well.