Bun 1.0 announcement [video]
youtube.com
youtube.com
Bun 1.0 is actually still compiling but we decided not to delay the premiere of this announcement video since it was already on calendars. We'll be publishing a full announcement post later today that's more detailed than this video.
Edit: Sorry it went down again. Not sure if this will be the eventual link.
The video is well done, and I'm fascinated that it's built on WebKit instead of V8. Good luck, Bun.team()!
[0]: https://github.com/ziglang/zig/issues?q=is%3Aopen+is%3Aissue...
Decoupling is of course possible, but the difference here is that the lang powering the runtime is not guaranteed to remain the same language it currently is, since it's in active initial development. That introduces a unique axis of risk to runtime stability, it's dishonest to pretend otherwise.
- Zig v0.11 doesn't have async/await, which I needed, because they haven't implemented it yet on the self-hosted compiler;
- I couldn't use v0.10 due to some bugs with comptime in the old compiler, which are solved in v0.11.
Still, while bold, I don't think it's totally unwarranted to tag Bun 1.0. They may have to put some extra effort here and there to work around the language's instability.
This is not a critique of the Zig team, they make it very clear that the language is not ready for production use yet.
the internals of bun may need to change when a new version of zig requires it, and the bun developers decide to use that version of zig, but existing versions of zig will continue to exist in the future.
future versions of bun can use existing turing complete versions of Zig if they ever decide to remove turing completeness from the language in the future.
lol
With a codebase this size theres a real chance of having miscompilations in there.
What's the points of running a safe language on broken infrastructure, it's garbage in garbage out.
And with Zigs recent plans to replace llvm with their own backend I'm not even sure if they won't continue scope creeping into vapourware.
You burn those CPUs in. You run them a bunch. Measure them. Measure their efficiency gains. If the gains are real, make a plan for scaling them up. Have fallback plans. The usual stuff. If a company has someone that does this as their job, they're on it.
If Bun affected your source code or development process, I would understand this perspective. Maybe don't use Bun-specific APIs yet, and just stick with the Node compatibility.
It's a 501(c)(3) non profit and has been open source since `git init`. Even the financials are transparent to the public. What else could we possibly do?
Given how few projects are written in it, the ROI of learning it is not that great.
I'm not 'against' Zig, it's just basic Lindy effect stuff. People don't want to build or invest in a foundation and then left hung out to dry.
Just like the rest of my development choices, I try to take calculated risk so that the platforms I'm building on have a high chance of lasting into the future.
We all know that a rewrite due to obsolescence can be the death knell for a project.
For many people reading and modifying the `bun` source code is likely something they could start doing tomorrow if they were so inclined, because they already know the semantics of Zig for the most part, and it's only a question of syntax.
If your argument is somehow that Rust, C++, Nim, D or some other alternative would do better in terms of on-ramping I can only shake my head and move on with my day, as they are all clearly much more complicated languages and they all happen to produce code that is much harder to understand from a performance perspective. If the argument is something even higher level and even more opaque in terms of performance-related behavior I think you've missed an important part of why Bun chose Zig.
In most cases that don't involve "I already know this language" the equation can never be much better than "You have to learn Zig/Odin". For every person that already knows the language in question there's a bunch that don't, and the only solution to that is quick on-ramping because it'll benefit everyone over time. It doesn't matter whether you know the language already if the language is mostly trivial to learn, read and use.
P.S.: If the argument is that C would be a better choice I don't disagree as wildly as I do with any of the other situations. C with custom allocators and a ton of static analysis added to it will be mostly fine, but both Odin and Zig provide great things on top of C in terms of basic language features without taking on too much complexity.
Sure - the Bun developers might have a super hard time if Zig changes its syntax, library APIs or other things. But that would be a maintenance hassle for the Bun developers, and not necessarily for the Bun users.
Of course text changelogs are always required, and I can only assume they will publish one today, but this Apple-ish format is very "eat a sandwich and watch something" compatible.
Nice job on the video to you and the team, and congrats on the 1.0 launch!
From the YT page:
"Bun 1.0 is here!
Bun is an all-in-one JavaScript runtime & toolkit designed for speed, complete with a bundler, test runner, and Node.js-compatible package manager."
There! Add a link or 2 to project page, status, FAQ or whatever, done.
Video is good for explaining some concepts in a visual way, or the cream on top for explaining other stuff.
The text change log will appear with the release, which is currently held back due to what sounds like a build issue.
- Workspace: check
- Bundling: check
- Minifying (server, browser): check
- Node runtime: check
- Browser runtime: check
- Loaders (assets, .node, .wasm): check
- Hot reload: check
It's probably worth trying to replace webpack + pnpm.
EDIT: Question: it is on roadmap to store downloaded file globally, like pnpm and maven do? This would be awesome!
Off-topic: Which equipment was used for the video?
I do wish the "each speaker holds the bun while talking" bit was kept the whole way through
On my small website, Bun is twice as fast pnpm which is already much faster than yarn which is much faster than npm.
Now that 1.0 is out I will give it another try. I could see myself migrating to it within a year if Bun’s performance and developer usability claims are justified
The two camera thing is a classic trick that lets you add some visual interest. Basically you're cutting between two angles. And you can only be looking directly at one camera at a time so you won't be looking into the lens for one of the two shots.
Oh wow, that sounds amazing. I would love an easy to way to use Rust crates from JS projects.
EDIT: I haven't been able to find that plugin or how it works, though. Looks like it's based on the esbuild pluing API?
It'd be really convenient to have a decently fast backend runtime, but more expressive than Go and without the hassle of NodeJS
Clojure is fairly interesting too, and it uses a similar async model to go.
I think the announcement video was a bit forced/awkward, obviously reading a prompt, professionally produced but maybe not the most efficient way to promote this tool for this team.