Since they did a one-to-one translation to start with, hypothetically, if these were the true numbers, you could probably get a static analysis tool to guarantee you that 97% of the zig code was safe and tell you which of the 3% were unsafe. Zig has a lot more syntax and conventions to encourage safe code compare to C after all. It just doesn’t have way to mark which parts are safe or unsafe.
An LLM could probably also trivially give you accurate reviews saying which parts were unsafe and in need of tests or reviews. I mean, considering their LLM budgets they could probably have had nightly reviews running every night for years before spending more than their Rust rewrite.
Not that I think Rust rewrite was a bad idea. Rust is a good fit for this kind of project. I say that as a Zig enthusiast. It’s just that their stated motivation and reported results are kinda BS. If they just wrote “we just like Rust and thought it’d be cool to see of LLM could do the whole rewrite”, and left it at that, I think it’d be a more honest description of the motivation. The rest is just rationalisation.
Why feel bad? If you’re using Zig to write a game or a system tool why should you care if Bun uses it or not? All this drama has very little impact on most users of Zig or its developers (some financial impact, but Andrew had already foreseen that as a risk and avoided depending on it)
libghostty is more impactful than Bun IMO. It doesn’t matter to most other developers that Bun was written in Zig, but that such a a good library is written in Zig could have an impact on whether other devs use Zig to write libraries, or if they consider Zig for their app when having libghostty as a dependency
TigerBeetle is also more important than Bun since Zig is a better match for their needs it was for Bun, and TigerBeetle team seems to be a better partner for the Zig foundation. The Bun/Oven team seemed to be an annoyance rather than a synergetic partner.
But in general, pre-1.0, I think any large project that uses it is just a bonus.
For posterity here are some comments I’m curious if will be deleted
1.
> Id like a clarification on how this is safer than Rust?
(Seems reasonable enough)
2. meme image with the words “bait” and “retarded” - should be deleted
3.
> Funny how memory safety suddenly became a priority right after Bun moved to Rust.
That feels like a pretty big departure from Zig's original philosophy.
> Someone's still pretty butthurt about Jared and the Bun team.
Just toxic negativity in my opinion. Author has clearly not followed Zig closely as memory safety has always been a priority as long as it doesn’t come at the expense of Zigs other more basic goals. This isn’t serious criticism and it’s completely valid to delete it. Andrew’s interest in Fil-C predates the Bun debacle AFAICT
I did notice one comment that was there before but which is now gone. But it was a completely unserious and garbage comment (just a comment dissing Zig)
And now I see a bunch more comments that are just utterly toxic, which I also expect will be deleted.
Serious comments seem to be kept, even when they’re sceptical.
I spend quite a bit of time in the Zig community, more as an outsider as I don’t contribute very much.
I really don’t see how you could find the community toxic unless you take everything they want to do differently from other languages (which may come along with some criticism - explicit or implicit) as some kind of toxic negativity?
“I'm tired to see zig head people trying to diss Rust whenever they can.”
I feel like in every Zig post you’ve got Walter Bright saying D did this 10 years ago and a bunch of other people saying Zig isn’t a robust language because it can’t do memory safety like Rust. I find it annoying, but it’s just how it is. We like to compare things we like and there will unavoidably be some negativity in there. We should try to steelman these comments. And the steelman case for Andrew’s mention of Rust here is that this is just a different approach to memory safety, and that’s it’s just more complete in the specific way he and Fil-C is referencing
I’ve seen many Zig enthusiasts who is positive to Rusts approach to memory safety (it’s definitely nice to catch things at compile time), but just don’t consider it the ultimate approach that is best for all kinds of software
“Here is the catch: that single integer is wearing three hats at once.”
How many times did that point have to be reiterated in unnecessary AI style?
Was the article AI generated. I hope so, if not it really shows how bad AI has degraded our ability to write. Could you at least have read over and cleaned up the prose a bit? That whole section could have been written in straight forward human language, and it would be shorter, clearer and less infuriating to read.
Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time.
I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs. It’s focused on eliminating one class of memory bugs in particular, exactly the class of bugs that are the biggest challenge for software like Bun, and other software with complex lifetimes (it originated from Mozilla and Rust is perfect for browsers)
Zig is intended to be robust for software like TigerBeetle, or the Zig compiler itself, where memory lifetimes are simple.
I’d say the focus on built in tests, fuzzing, debug memory allocators and safe mode shows that Zig is absolutely intended to be robust, within the scope of what the language aims to be. Far more than C itself or most of its popular compilers ever did.
That’s totally reasonable. But while each minor version has breaking change, a minor version release itself is generally fairly stable and useable. There are solid production software which is already using Zig, like TigerBeetle and Ghostty/libghostty.
I am waiting for (near) 1.0 myself before doing anything major with it. But that’s mainly because I want at least the async IO stuff to be settled for my use cases.
Zig itself is an incredibly fast compiler. And the language and standard library is designed to support writing that compilers. And yeah, that’s all about algorithm and data structures. A large part of why struct-of-arrays is easy to do in Zig is because Andrew wanted it for making the compiler fast. The article also points out that it’s reusing code from the Zig compiler source as well.
Roc may not be super fast now, but that doesn’t mean they haven’t seen ahead and set themselves up for success.
Yeah, I agree there is value in self-hosting as you say. Zig itself is an example of that. But zig is a systems language. If Roc isn’t aiming for that nice it might not be the best choice for writing a compiler in. As an example in the other extreme end of language flavours: Python is still mainly CPython and efforts to make a python interpreter in some variant of python hasn’t been particularly successful.
The results improving the end user experience didn’t have much to do with the rewrite. Improvements in binary size and speed could be had with similar efforts on the Zig codebase. They spent extra effort to get those metrics to look good to sell the rewrite.
The memory safety aspects could be discussed. Arguably they could have had equally good memory safety by employing AI, tests and fuzzing (the Zig integrated fuzzer that the Zig team suggested they use, not just the high level fuzzing they were doing)
For this kind of project I do think using Rust is a good idea. At the very least because a project like Bun probably can benefit from a more mature language.
But I also think Andrew’s perspective of this process has been essential to understand what happened here, and though he could have been nicer with his word selection in a couple of places (he doesn’t have the clout of Linus Torvalds to get away with it), what he wrote absolutely needed to be said. I find it annoying that people dismiss it as personal attacks. If being a bad manager is the direct cause of a poor working relationship and bad engineering results, pointing it out is not a personal attacks. It’s essential context for understanding what happened.
How can it linger in a higher orbit. Maybe some of the debris gets a kick which increases its velocity, but you need two velocity boosts to circularise the orbit, no? So I figure at worst you get an elliptical orbit which will still decay
I have the exact opposite impression. From everything else I’ve seen around Andrew and the Zig Foundation he is extremely professional and skilled with managing community. In fact I’d say the community and management of the project is Zigs biggest strength.
This blog post only reinforces this opinion. It is clear that the Zig developers has had huge issues with his relationship with Bun for a long time, and it seems from both Jarred and Andrew’s post that Andrew really put all those issues aside, in spite of his strong personal opinions, to maintain a professional and productive relationship as long as possible.
It’s only now that the relationship is broken (on Buns initiative) that he has taken the opportunity to vent a bit. And I’m really glad he did.
It’s similar to Linus. Sometimes Linus goes too far in his comments. But getting an occasional insight into people’s personal opinion is good, as long as it’s not at the cost of breaking a professional relationship.
I didn’t read the beginner energy comment as faux positive at all. In fact Andrew has commented about his own beginner energy just recently and shared some embarrassing forum post he made as a teenager.
Stinky manager.. I could see, but even if his wording was more polite he’d still be criticised just as much, people would just say the personal criticism is “thinly veiled”.
We could argue a lot about how he should have worded himself, but in the end he wanted to (and had all right) to talk about how Jarreds coding and management style affected their professional relationship. According to commenters here on hacker news it seems like he simply is not allowed to talk about that. Even if he goes as far as possible in making it explicit that it’s not personal.
> You didn't see K&R publish "so-and-so writes bad C", or Stroustrup decrying the Boost maintainers as hacks.
The world is completely different now. The VC fuelled culture was not as intense and LLMs certainly didn’t exist at all. Andrew calls out these factors explicitly.
> He can't have both "It's their fault because their code was slop" and "it's not my business".
Huh? But it was his business when they had a relationship. Seems he was trying his best to work with them while they were getting funding and Bun was interested in them. That’s the nice thing to do no? Even if you don’t like the partner.
Imagine if the Zig foundation broke the relationship from their side, that would have been much worse.
I don’t think Andrew was trying to say it wasn’t his business in that way. But in the end he couldn’t control what Bun did or didn’t do, and now it’s not his business in any way.
How often do stuff fall of the rails, and how common is derailment? In case of derailment you’ve got much bigger problems than some broken solar panels.
It’s not easy though. When we started with html we assumed images could only have one source. It was obvious that cardinality was 1. Later we realised we could have multiple versions of the same image. With audio tags that was resolved.
I’ve come to realise that it’s almost always a mistake to assume a cardinality of 1, unless it’s something that is defined to be artificially unique like the id attribute.
I don’t think it’s about being a spectrum. It’s about having different paths to the same goal. GC is one well-proven path. Rust / Borrow checker is another path, with other benefits and limitations. Zig is well on its way to a third path with potentially the same level of safety and different benefits and limitations.
Zig will depend on having tests with good coverage, and you should probably use fuzzing. But if you care about safety and stability, why would you not write tests? Memory bugs are not the only class of safety and stability issues we should care about. So I don’t think we should be dismissive of an approach that takes a more holistic approach to those, while also providing really solid memory safety.
I am sure we will see solid static analysis tools for Zig which can weed out a lot of stuff before runtime as well. The developers of the language seem very interested in that approach but need to focus on other things first.
The most interesting killer application for Zig is perhaps Ghostty and its library libghostty, which will probably be fairly easy to integrate with C apps since Zig is close enough to C.
There’s also Tigerbeetle, but unlike libghostty its use of Zig doesn’t have much chance of being viral.
I think libraries that can be used by many other languages is Zigs chance to wide adoption. And this ties nicely with Zigs fantastic build system, which may become increasingly popular for C based projects, especially where cross compilation is important.
An LLM could probably also trivially give you accurate reviews saying which parts were unsafe and in need of tests or reviews. I mean, considering their LLM budgets they could probably have had nightly reviews running every night for years before spending more than their Rust rewrite.
Not that I think Rust rewrite was a bad idea. Rust is a good fit for this kind of project. I say that as a Zig enthusiast. It’s just that their stated motivation and reported results are kinda BS. If they just wrote “we just like Rust and thought it’d be cool to see of LLM could do the whole rewrite”, and left it at that, I think it’d be a more honest description of the motivation. The rest is just rationalisation.