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.
Despite the 1.0 release tag, given that it's written in Zig, which is super duper Alpha, I'd trust it only as far as I can throw a floppy with its source code.
I don't have any opinion on Bun itself. But as someone who is pretty experienced in running large scale services, I wouldn't have a problem to use a tool that is marked as stable but internally built on top of unstable tools. As long as compilation is mostly deterministic (which is usually given for compilers), a good set of unit and integration tests should prove that the software is actually doing what its supposed to do and can be trusted with workloads. If those tests are not available, then even using a mature language might not provide a guarantee that the actual product is better.
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.
A project can only be as reliable as its compiler. Zig currently suffers from a number of miscompilation [0] that is quite higher than for a more mature compiler.
It matters plenty if your production system goes down because of bugs caused by miscompilation of your js runtime. This level of instability doesn't uphold the social contract that a 1.0 implies.
It does worry me as a potential adopter of Bun what the long term outlook of the project is if the language used to write Bun isn't very accessible to prospective open source contributors.
You seem to be implying that zig is not open source or is otherwise unfriendly to contributions...?
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?
Zig being a language that most people are not familiar with is a very high barrier of entry in it of itself.
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.
I’m not saying they’re not friendly, I’m just saying learning a new language for probably the single purpose of contributing to this repo is a pretty high barrier of entry for contributors. It is great you overcame it.
Learning Zig is a very low barrier to entry. From experience I can tell you that learning the language is a matter of weeks and most of the code in the wild will be very accessible to you once you've done that, because there aren't as many different plateaus of skill in Zig as you would find in many other languages.
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.
I don't know what to tell you. I don't know many languages that have a shorter on-ramp than Zig (or Odin). The obvious relevant language here would be Go, but Go wouldn't be as desirable in terms of producing as good results in a confident way; Zig (and Odin) is a lot easier to spot performance deficiencies in.
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.
That's like saying data centers shouldn't use slightly faster CPUs because they aren't tested yet.
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.
Changes to Zig can still be very significant. I found myself stuck between a rock and an hard place when I found out that:
- 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.
True, though you can't claim that's an analogous situation - C++ wasn't in alpha when the JVM was implemented.
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.
Well sure if you start adding more conditionals and change the original question you can call anyone who answered the original question in good faith a liar.
That's not what happened here. If you have difficulty keeping context of the thread we're all in, scroll up and reread. Snarking (and being wrong to boot) contributes nothing to the discussion.
are you saying that zig is currently turing complete and that in the future it might not be? because that's the only thing that could force a change to what is possible in the language.
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.
Unrelated to the release itself: I like this direct format of video changelog. It's pretty slick, and doesn't spend too much time meandering.
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.
We are releasing a proper announcement later! This video was scheduled to premiere at 10am but due to some last minute bugs (and Murphy's Law) the build didn't finish in time. We decided not to delay the premiere because it was already on calendars and whatnot.
I've not used Bun (yet), but this video managed to be to the point while delivering the information in a way that I probably would have skimmed through if reading a blog entry.
I do wish the "each speaker holds the bun while talking" bit was kept the whole way through
I played with Bun around a year ago. Looked promising, but was not an easy drop in replacement for nodejs in my projects. I don’t recall the issues and give Bun’s beta state I didn’t give it much effort.
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
In addition to FFI, socket, package manager and build system performance, I really wish to somehow automagically improve (similar to zero cost abstraction of Rust) my existing business logic in NodeJS which uses methods like map, filter reduce along with utility libraries like Lodash and RamdaJS etc. which are super helpful but causes lot of object allocations underneath.
Nearly totally unrelated, but what is with the recent trend of showing people talking to but not look at the camera? Do they save money that way? It drives me bananas and is just a distraction from the content being conveyed.. Altogether, with their obvious attempt at slickness, I find this video rather corny.
This video is definitely corny. (I'm in it.) This is intended as an extremely accessible introduction to Bun, definitely not targeted at the HN crowd. I think we really just wanted to make something with some production value to reflect the fact that Bun itself is post-1.0 and more stable/polished.
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.
Having someone look directly at the camera can sometimes feel unnerving in video. Also it's a good way to hide a teleprompter and the side-to-side eye movement
I'm not sure about unnerving. Psychologically, I know I'm looking at a recording. But when they're not looking at the viewer, it looks like they've got better things to do.
I see this being used all the time recently, including on large productions. I assumed it's meant to convey the feeling of talking with someone who may also be talking to others. But it gives me hives (for which I'm losing points, but what can I say).
If the performance improvements are that extensive, it would be interesting to see how close JavaScript + bun would get us to Go or Java on the backend. It would be a game changer if that gap can be closed.
I’ve been playing with Rust as a web backend, and while I still feel really unsure about it, I’ve been surprisingly productive. With that, I occasionally run into some issue with async or lifetimes or pinning that really slows me down, though I’m unsure if that’s partly being a beginner.
Clojure is fairly interesting too, and it uses a similar async model to go.
The performance differences are so large (5x, 6x, and 18x faster) that I can't believe them. Is bun really faster on large codebases, not just on hello world?
Yes. I found it to be about 2x as fast on a real world project when I kicked the tires 6 months ago or so. I’m sure it varies quite a bit based on the project internals.
Very nice project, not a tool I would use (I rarely use Javascript) but I like the design philosophy behind it, and the focus on performance and simplicity.
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.
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.