I am not sure I believe the argument about memory leaks, because if anything, it should be easier to fix those in Zig.
But given that they’ve been acquired by Anthropic and they likely have infinite amount of tokens at their disposal, I think Rust makes sense for them because:
Rust compiler produces very readable compile errors, often with clear resolution strategy, whereas Zig errors can be very cryptic (and if agents are really good at something, it’s when you’re able to “close to loop” either with tests, or with clear compile errors)
It has been already pointed in the other thread but some Zig features (unused, unique names, const/var) are hard to swallow not just for me and other people in that thread, but also for AI, and it’s just burning tokens for nothing. Just like me, when I write some first version, then hit compile error, and then I have to come up with a different name, change var to const, etc. All of that could be quite expensive. And I don’t want to start this debate again but it’s really telling you something about Zig (no matter how much I love the language)
Even if they wanted to improve this, Zig anti-AI policy prevents them to do so (in practice)
Given that they’ve ported Zig to Rust, the perf is likely going to be the same. Zig is usually faster because of the style you have to adopt, that is different from how idiomatic Rust looks like, so I wouldn’t expect a lot of downsides except of lots of unsafe {} blocks and headaches in order to get rid of them.
I personally think they are going to switch to Rust. And I think it’s going to bite them eventually, but that’s a different story.
BTW: What I think they should do instead is to consider switching from JSC to V8 and try to use their Oilpan GC as Zig allocator, that’s something I’d do in order to avoid mem leaks (and maybe even eliminate them entirely, by design).
As the tigerbeetle people like to say, correctness is a holistic property of the system, not something that can be easily solved by tackling isolated aspects (eg the language).
There are structural reasons why Bun got to the place it is and, unless those change, changing the language can maybe make a marginal improvement, but otherwise nothing has really changed.
As an example Bun has wrong asserts that cause UB in ReleaseFast. A more correctness-conscious company would have for example started distributing ReleaseSafe builds in order to get actionable bug reports and eventually get to a point where they could turn ReleaseFast back on (maybe). Bun instead bans usage of std.debug.assert and replaces them with an implementation of assert that just turns off the assert in ReleaseFast builds (???).
I do hope that the switch to Rust will prompt a re-evaluation of the way certain things are done though.
I think it’s an interesting project for sure, but just like you I don’t think it’s going to miraculously solve all their problems, And the thing that boggles my mind even more is that they seem to enjoy the fast feedback loop with Zig, even went as far as forking the compiler and throwing tokens at making it faster (at the cost of correctness). But I think they are going to become nuts with the time it takes to compile even trivial Rust projects.
Like there’s an entire craft out there just like in C++ where you have to write and organize your code a certain way to optimize the compile time, and even then it’s still multiple orders of magnitude slower than Zig, or C.
I think Rust is probably better suited for their level of vibe coding, and any language which uses LLVM, can expect about the same kind of performance with the right architecture, and code.
I can’t talk for all the Rust projects of course, but all the ones that I’ve come to liked and use (like Helix for example) I’ve seen tremendous slowdown in shipping features over the years, and I, from following the issue trackers and the conversation closely, And adding my limited experience with Rust. It seems like as Rust project grows, it becomes harder and harder to really evolve the system, and refactors are really tedious.
Yet one of the thing with Bun is that they seemed to shipped features at an insane rate, and I’m not sure that Rust will necessarily be as enjoyable and agile as Zig was, maybe I’m wrong, only time will tell.
Yes, it’s bizarre how rarely the JSC dependency is questioned. There was never as strong a reason for it as people claimed. It became an annoying piece of received wisdom.
Zig gives you a lot more freedom and power, it’s got the best C interface you can get, has an oustanding compiler, etc etc - but if you don’t need that, and only care about speed and correctness (a lot of use cases) - Rust is easy street compared to Zig.
It might be easier, but that does not mean they are right way to solve the problems. Most of the stuff in low level programming cannot even be attempted with “safe rust” and they can be simpler, easier to understand and “right way” to solve the problems.
Also for correctness and speed is important, please use Ada and SPARK. Rust is nowhere close to that. Ada solved most of the things Rust is attempting to solve 40 years ago.
Zig still has a lot of issues around stack reference escape, stack usage and stack reclaiming. Bun in particular hits them in Zig. See links at bottom.
I believe that Rust will stop 100% of those kinds of crashes.
I started using Rust before 1.0 as a hobby, and I really enjoyed the language for many years. Then, async happened, and I fully stopped using it at all.
If I would be the Bun dude I would basically experiment with whether the LLM he used for porting the Zig code to Rust can also pinpoint the memory corruption issues in the original Zig code (which might or might not have been fixed with the Rust port since I remeber reading that most of the port is inside unsafe {}.
E.g. if LLMs can identify most memory corruption issues in Zig (or C) code that would be a damn fine reason to not bother with Rust but instead continue using “unsafe” languages that are less hassle to work with
Am I going crazy here, or has Bun, ever since they ramped up LLM usage become more unstable and buggy than before? How would a complete LLM rewrite help address this? Is the premise that the Rust compiler finds more bugs than other compilers? Isn’t the whole selling point (allegedly) of agentic programming that it will find bugs humans would not, why couldn’t they just ask the their LLM to analyze the existing codebase for bugs? Seems like it would be a much safer and better use of their time than migrating it all to a completely new language. Honestly a bit baffled by how quickly they made this decision, on the surface it seems incredibly short-sighted and potentially catastrophic. I guess we will see how this ages the coming months.
Deno has a business model. No, I don’t know how profotable they are, but they have one. Bun needed to find one. This makes Bun a more interesting acquisition. But maybe Deno just denied an offer.
