I'm not. Andrew Kelley's blog posts often have blunt and/or abrasive language. To the point where the discussion of his writing is often sidelined by talk of how uncouth it is. The instance that...
I'm a little surprised by the overall tone of the blog post.
I'm not. Andrew Kelley's blog posts often have blunt and/or abrasive language. To the point where the discussion of his writing is often sidelined by talk of how uncouth it is.
The instance that comes to mind was his post discussing Zig's move away from GitHub, that had some language that was so abrasive that it went through multiple editing passes after publishing.
The edit history of the announcement is quite a ride:
[2025-11-27T02:10:07Z] it’s abundantly clear that the talented folks who used to work on the product have moved on to bigger and better things, with the remaining losers eager to inflict some kind of bloated, buggy JavaScript framework on us in the name of progress (web.archive.org)
[2025-11-27T14:04:47Z] it’s abundantly clear that the talented folks who used to work on the product have moved on to bigger and better things, with the remaining rookies eager to inflict some kind of bloated, buggy JavaScript framework on us in the name of progress (web.archive.org)
[2025-11-28T09:21:12Z] it’s abundantly clear that the engineering excellence that created GitHub’s success is no longer driving it (web.archive.org)
It was a great read, thanks for posting. I dabbled in Zig some time back on a journey to familiarise myself with a bunch of the "new" languages on the block. Zig, Rust, Go, Chef, that sort of...
It was a great read, thanks for posting. I dabbled in Zig some time back on a journey to familiarise myself with a bunch of the "new" languages on the block. Zig, Rust, Go, Chef, that sort of thing. I can't think I'll have an actual real world use case for it though.
I do read / hear / watch a lot of stories about AI contributions to FOSS projects though, both direct contributions and bug reports, and almost none of it is positive.
Holy crap, I'm never touching Zig or Bun with a ten foot pole. What a bunch of unprofessional jerks. So what they're saying is, if I use their obscure language and ask for help (or even donate!)...
Holy crap, I'm never touching Zig or Bun with a ten foot pole. What a bunch of unprofessional jerks.
The post claims they were fuzzing their Zig code, while during our calls the whole Bun team told us that they were not fuzzing anything. This appears to be an outright fabrication.
So what they're saying is, if I use their obscure language and ask for help (or even donate!) -- then dare criticise them -- they'll whip out the call logs to start railing me in the socials? What the heck?
Bun always gave me the ick, and Zig felt like a solution in search of a problem. I've had the privilege of working with genuine professionals: they could wipe the floor with me engineering-wise, and were level headed when the seas became rough. But these guys ain't it. They really deserved each other.
Ehhh given the context of the Bun author posting a blog making potentially false claims about the language I do think Zig gets to defend themselves. If they just dropped this after Bun moved to...
Ehhh given the context of the Bun author posting a blog making potentially false claims about the language I do think Zig gets to defend themselves.
If they just dropped this after Bun moved to Rust it’d be bullshit but given they straight up said “oh yeah zig just can’t scale we were doing it right” I think you get to counter, especially if you have reason to believe it’s a blatant lie.
I am curious what all the fallout from this will be. It strikes me that both sides have objectively provable claims(either zig doesn’t scale well in buns case or bun had slop code) so it shouldn’t be that hard to point to “like this line here” but so far there’s a lack of that
I ... guess? I suppose I'm used to e.g. Bjarne Stroustrup not coming out swinging whenever someone bails on C++ for, like, D or something. Or I guess Oracle dropping a diss track for every press...
I ... guess? I suppose I'm used to e.g. Bjarne Stroustrup not coming out swinging whenever someone bails on C++ for, like, D or something. Or I guess Oracle dropping a diss track for every press release praising Kotlin. And there doesn't seem to be animosity between the Kotlin and Dart crews.
If someone stops using your project then great, more power to them. If they misunderstood the assignment, and had been misusing your tool the whole time, then I guess that's on them. The need to "well ackshually" every critique leveled against your project via competing open letters is a trend that I've grown to despise in the modern software development community.
I'm probably just being nostalgic for the bygone days of yore, where the people engaging in the language wars were just us sweaty code monkeys, swinging away in the pits. It's very odd to see this sort of poop slinging being done by the ostensible responsible adults in the room.
I am curious what all the fallout from this will be. It strikes me that both sides have objectively provable claims(either zig doesn’t scale well in buns case or bun had slop code) so it shouldn’t be that hard to point to “like this line here” but so far there’s a lack of that
I don't think those are objectively provable? I can jump into nearly any codebase and find regrettable choices, especially once they crack the mid-five digits. Similarly, you can find C++ projects pushing several hundred thousand lines which compile faster than mid-sized Rust projects, because the people architecting them understand how to leverage their (admittedly, distributed and caching 😅) compiler toolchains extremely well. So ... everything can scale. And everything can be written poorly. IMO at least.
Comparing programming languages is super difficult, which is why I've historically selected them based primarily on what I know about the teams that're going to support them. I'd choose a vanilla TS/JS project ten out of ten times if I knew the crew that was running it was allergic to Kotlin Jetpack, but if the app devs needed to stretch their wings out into a small web service, I'd lean towards the tool they already know.
(edit) Sorry; I let this go unstated in my original message, but to note it: I'm aware that this is a marketing stunt done by some egotistical jerks manipulating their respective communities into donating their time, money, or mindshare. That's just the core of what's disappointing here.
On the other side though this is a big issue. If multiple people come out and just say "yeah zig doesn't scale" that's a problem, and a major project is a very loud datapoint on that. We know the...
I'm probably just being nostalgic for the bygone days of yore, where the people engaging in the language wars were just us sweaty code monkeys, swinging away in the pits. It's very odd to see this sort of poop slinging being done by the ostensible responsible adults in the room.
On the other side though this is a big issue. If multiple people come out and just say "yeah zig doesn't scale" that's a problem, and a major project is a very loud datapoint on that.
We know the weaknesses of languages like C/Java/JS/Etc, but with newer languages the more they're tested the more we learn.
Even ignoring the money in the room, this is how coders have discussed this stuff. Linus is not known for his private beatdowns, it just wasn't as visible because you had to be a linux kernal dev or interested in that to even see it. It had similar ramifications though in that the outcomes of those shit slinging sessions often would determine major standards and tech adoption.
When everyone swears their product is the best (again nothing really new, just inflated thanks to the money) getting valid data points is important, and if you just hear "oh wow Zig just can't handle catching some memory errors while rust can" that's a BIG statement given that is probably one of THE largest problems in coding and any tool in this day and age not solving it leads you back to "might as well use C, at least I can hire for it" or similar problems.
I don't think those are objectively provable?
Depends. Both sides could be providing code snippets they thought were unreasonable. It's not some awkward "well in this environment" performance metric which can be bullet proof or wildly variable. Both posts would be a lot more powerful with a "For example" code block of what they thought was being done right or wrong. If it's as egregious as they're both claiming (one migrating to a new lang, one saying they write out and out slop) that should be fairly easy to identify.
Yes if the answer is "well we have some slop, we all do" that's trickier, but we don't even have a starting point for reference to judge that.
IMO, understanding where tools have fallen short doesn't make them good or bad on a flat, 1d spectrum, it just indicates where the risks could be in adoption. Even if it can't "scale" (for however...
On the other side though this is a big issue. If multiple people come out and just say "yeah zig doesn't scale" that's a problem, and a major project is a very loud datapoint on that.
IMO, understanding where tools have fallen short doesn't make them good or bad on a flat, 1d spectrum, it just indicates where the risks could be in adoption. Even if it can't "scale" (for however the term is being used in this case), that still doesn't remove its other proven benefits. Bun's post on this is extremely verbose, but IMO since every tool has a set of tradeoffs associated with it, it's still very informative: not everyone is the literal creator of Zig and capable of writing pristine code.
If we were actually doing software engineering, the takeaway from viewing a failure would not be "oh no this whole thing is bad! We'll never use any of these tools!", it would be understanding the root causes of those issues in order to better develop plans to avoid them, since all tools have flaws and nothing is perfect. Analogously: just because a house catches fire once doesn't mean we should stop building houses and return to the caves -- which are clearly the superior form of housing, since they don't catch fire!! -- because everything is a tradeoff. People like having walls, and windows, and etc. So the takeaway should be to install fire sprinklers, or AFCIs, not to discard an entire toolchain because someone rich and super smart wrote some blogspam about how they've abandoned the surface world. The weird, uncritical, cargo cultness of software development really irks me.
But that's a subtle point. I think people love the language benchmark game or the TIOBE index since they provide a clear and unambiguous ranking of an otherwise complicated problem, which -- ultimately -- generally has little to no impact on your team's ability to execute on a given project. Given the number of projects barely limping on with extraordinarily subpar stacks in the world (lord knows I've seen enough of them), we have existence proofs that one can accomplish basically everything with anything these days, delta some realtime-critical applications.
oh wow Zig just can't handle catching some memory errors while rust can
Quick sidebar: it can't though, can it? Zig doesn't appear to have a borrow checker, and from a skim, it doesn't have a GC either (or ARC). Assuming you were thinking of memory leaks when you mentioned errors? (and not, like, use-after-free, array bounds checking, or etc.) Also also we kinda solved this with garbage collection a couple decades ago; for whatever reason, marketing teams have successfully unsolved it for many folks, but I've very rarely seen GC behaviour cause an issue under load where there wasn't some underlying problem (e.g. memory leaks in unmanaged pools, or some algorithmic error which would've thrashed a manual allocator anyhow).
Both sides could be providing code snippets they thought were unreasonable.
I fundamentally don't understand what quoting snippets at each other would do in this case, though. Like, is the goal to learn what went wrong, so we can do better as an industry? It really feels like petty squabbling.
Linus is not known for his private beatdowns, it just wasn't as visible because you had to be a linux kernal dev or interested in that to even see it. It had similar ramifications though in that the outcomes of those shit slinging sessions often would determine major standards and tech adoption.
Just addressing this separately, but imo Linux isn't a great example: languages are a dime a dozen (Zig is an uncomfortable middle child between golang, Rust, and C++), and they can be swapped out pretty easily and without major consequence. If one project catches fire and explodes, sure, fine, do a rewrite and move on.
If the Linux project went down -- especially for a critical decade or two in there -- I'm not sure another project could've taken up the reigns? Sure we have some weird nix's in there (GUIX, Solaris, ... Darwin (_shudders)) ...), but they weren't anywhere near as mature or multipurpose. Linux can work on anything from your microwave to a car to a supercomputer, which would've been extremely challenging to reproduce in another OS.
I don't know what it would even mean if Linux "went down." If some controversy happened, the various Linux distributions and tech companies that use the Linux kernel could start up a new fork...
I don't know what it would even mean if Linux "went down." If some controversy happened, the various Linux distributions and tech companies that use the Linux kernel could start up a new fork pretty quick, like Redis / Valkey.
Ah, apologies, I should've been more precise. The context of this discussion is comparing Linus' jackassery to Andrew's, with respect to defending the honour of their respective OSS projects. I'm...
Ah, apologies, I should've been more precise. The context of this discussion is comparing Linus' jackassery to Andrew's, with respect to defending the honour of their respective OSS projects. I'm claiming that a broad drop in confidence in Zig's ability to perform as a programming language is orders of magnitude less important to the software development community as a whole than Linux's. I don't feel that either maintainer's response is appropriate, but since there are actual stakes at play if the industry as a whole decides to move on from Linux because someone powerful dictates that "it can't scale" or something, it doesn't seem like an apt comparison.
Taken to its logical extremes, if we accept that toddlers can cry because they can't have juice after bedtime, does that justify Andrew throwing a tantrum because a donor pulled out?
No i'm definitely summarizing and essentially agree, but I've met the kind of people who thought everything should be made with JS (before TS even existed), and I think seeing a language in the...
IMO, understanding where tools have fallen short doesn't make them good or bad on a flat,
No i'm definitely summarizing and essentially agree, but I've met the kind of people who thought everything should be made with JS (before TS even existed), and I think seeing a language in the wild/reality is important. Things that don't matter for one scope matter a LOT for another, and given "will i need to manually handle memory" is one of the biggest decisions at the product creation, Zig's performance there on a major product strikes me as very very important.
Quick sidebar: it can't though, can it? Zig doesn't appear to have a borrow checker, and from a skim, it doesn't have a GC either (or ARC). Assuming you were thinking of memory leaks when you mentioned errors? (and not, like, use-after-free, array bounds checking, or etc.) Also also we kinda solved this with garbage collection a couple decades ago; for whatever reason, marketing teams have successfully unsolved it for many folks, but I've very rarely seen GC behaviour cause an issue under load where there wasn't some underlying problem (e.g. memory leaks in unmanaged pools, or some algorithmic error which would've thrashed a manual allocator anyhow).
It cannot, and neither can rust fully catch them. To quote the Bun dev (search for Jarred. I can't link directly to a comment sadly):
For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors or automatic cleanup.
So:
Yes it includes use-after-free
"solving this with GC" is.....kinda wild take to me. GC IS overly stigmatized for dumb reasons. I will never have need of a non GC language for anything I'm likely to do. However I have friends who absolutely cannot use a GC language for their line of work due to the performance requirements they need to meet. This is the core of coder discussions basically since GC was popularized, in asking is the GC security worth the performance overhead. It isn't helped by languages like JS/Python tending to perform worse than they should due to quality of code or language decisions. I know very little about Bun, but I'd assume their performance demands are enough that just porting/building in a GC lang to start wasn't an option.
I fundamentally don't understand what quoting snippets at each other would do in this case, though. Like, is the goal to learn what went wrong, so we can do better as an industry? It really feels like petty squabbling.
Because it's proof of reality so we can learn what went wrong? I don't just ask my team "what do you think went wrong?". I often want to see it so I can discuss if it was a reasonable mistake or a footgun they need to watch out for.
For the record this blog's claim that they "outright lied" has been countered with this comment (same as above but I think its the top comment?). Now I don't have enough expertise to know if that's a real counter or not, and it sure seems like there's still plenty of back and forth discussion on it on if this is relevant or just "well yeah right before you ported you started fuzzing". At least it's a valid and provable data point though for someone trying to consider if the claims being made are real.
A random blog writeup that is inherently biased (in both cases) strikes me as a less than useful datapoint. Git activity and actual code gives plenty of real examples to dive into to at least asses "oh god Zig will be a minefield of gotcha's" or "jesus no wonder Bun is whining, this code is crap".
Just addressing this separately, but imo Linux isn't a great example:
I mean...I still think it holds. Linus is not an outlier in behavior. It's not really a secret that coding has attracted some difficult personalities who like to wave it around. Jobs is more "tech" and was hardly timid and more specific to me the lead datastar dev strikes me as his own worst enemy. Lot more "Jobs" than "wozniak" heading most of these projects, and it always has been. It's just more front and center now.
Aaaaugh HN. I hoped never to see that orange banner again. I think you're linking to this comment? You can get a direct link by clicking the "X days ago" text. Agreed re. JS. People've been...
Aaaaugh HN. I hoped never to see that orange banner again. I think you're linking to this comment? You can get a direct link by clicking the "X days ago" text.
No i'm definitely summarizing and essentially agree, but I've met the kind of people who thought everything should be made with JS (before TS even existed), and I think seeing a language in the wild/reality is important. Things that don't matter for one scope matter a LOT for another, and given "will i need to manually handle memory" is one of the biggest decisions at the product creation, Zig's performance there on a major product strikes me as very very important.
Agreed re. JS. People've been zealots for their favourite tools forever. But it's disappointing to me that a debate akin to Milwaukee vs. Dewalt seems to be elevated to the level of pseudoscience (pseudoengineering?) in software dev circles, whereas -- afaict -- tradesfolk are generally not actually frothing at the mouth crazy when they defend their preferred power tool colour. Dunno, maybe people with more experience can chime in; I only have Reddit comments to rely on.
It cannot, and neither can rust fully catch them.
Yep. Not sure where the framing of my claim that Rust fully solves "them" came from. Your full statement was:
When everyone swears their product is the best (again nothing really new, just inflated thanks to the money) getting valid data points is important, and if you just hear "oh wow Zig just can't handle catching some memory errors while rust can" that's a BIG statement given that is probably one of THE largest problems in coding and any tool in this day and age not solving it leads you back to "might as well use C, at least I can hire for it" or similar problems.
My response was that it is provably the case that Zig can't handle some memory errors while Rust can. I was not making a universal statement, so I'm not sure why I'm being framed as having done so.
"solving this with GC" is.....kinda wild take to me. [...] However I have friends who absolutely cannot use a GC language for their line of work due to the performance requirements they need to meet.
Ah, that's on me; I added a statement in out-of-sequence in a previous paragraph to couch my claim:
[...] delta some realtime-critical applications.
High frequency trading, aerospace, or nuclear control systems, all of which have liveness and realtime constraints which a GC generally cannot meet. Please note, though, that the statistically average professional software developer is writing with a language that would be a PIA to extract the GC from (Stack Overflow 2024 Survey; to my eye, maybe 15% -- optimistically -- used Rust/C++/C that year) so evidence strongly leans towards the observation that GCs must have solved a huge section of these problems for the overwhelming majority of situations. Either that, or 85% of programs don't have this problem to begin with, so we're back to saying it's only a minority concern.
Please understand that I am not stating that every memory-related software defect can be addressed with a GC. I am stating that a GC fixes the problems that a GC fixes, that Rust's borrow checker fixes what Rust's borrow checker fixes, and Zig's arena allocators (iirc that's how it handles memory allocation) fix what Zig's arena allocators fix. These all correspond to addressing a not-necessarily-overlapping set of defects in applications. The claim I made was that there are a large set of memory use-related errors that Rust prohibits at compile time (when using the borrow checker properly) which Zig will not (without excessive hoop jumping).
Re. Bun and the necessity of garbage collection, all I can point to are Maven, Gradle, Bazel, and all the existing Javascript tooling to say that they didn't need to abandon the GC to hit whatever their performance goals are unless they're extremely memory constrained for some reason. Bazel especially rips through enormous builds by dint of running a persistent build daemon. To be precise about my point: "performance" is squirrelly and ill-defined. We have evidence that, for some definition of "performant", we can build performant build systems that use GCs.
A random blog writeup that is inherently biased (in both cases) strikes me as a less than useful datapoint. Git activity and actual code gives plenty of real examples to dive into to at least asses "oh god Zig will be a minefield of gotcha's" or "jesus no wonder Bun is whining, this code is crap".
I think we're in agreement? I'm once again being bitten by my terrible communication skills. I was trying to imply that a third party's coherent, low bias analysis of the problem is what's necessary for coming to any reasonable conclusion. When each side slings isolated fragments of evidence at one another, we lose the context, distribution, and frequency information which is critical for understanding if they're e.g. cherry picking in order to "win" the debate.
Assuming it's true, I think it's entirely reasonable to share this with the world. I wish more people participated in free exchange of information like this. Far too much is held back out of...
Assuming it's true, I think it's entirely reasonable to share this with the world. I wish more people participated in free exchange of information like this. Far too much is held back out of politeness leaving people ignorant.
The blog post amounts to "He's got what he wants, his project is no longer my burden, oh and this bit was a lie". It's the kind of professionalism I think Silicon Valley needs more of. For example, I've met a founder in SF who I'm pretty sure is a sociopath. I heard him say some wild stuff about his employees. I wish I could share that stuff with the world to alert people in advanced, but I don't really have the means.
Strong disagree. They're acting like consultants in this scenario: a fee is paid to their organization so that they'll listen to your concerns, and then provide advice on how to fix them. We truly...
I think it's entirely reasonable to share this with the world.
Strong disagree. They're acting like consultants in this scenario: a fee is paid to their organization so that they'll listen to your concerns, and then provide advice on how to fix them. We truly should not create the norm that consultants leak your dirty laundry: the entire point is that you can be fully open with them, but if you need to hold information back for fear of their badmouthing you later, then the entire relationship is soured.
To be clear: I'm not talking about actually important things, like exposing SA or whatnot. This is just business. When two groups of people speak with the expectation of privacy, violating that trust is a bridge you can't uncross.
For example, I've met a founder in SF who I'm pretty sure is a sociopath. I heard him say some wild stuff about his employees.
Mmhm, and same. But that's very different than trashing someone's reputation given your insider knowledge because they've broken ties.
I dunno; I get that people want others to be more open in general, but this feels like if your doctor started a blog describing how much of a piece of crap their patients in particular are, and called them out by name. It seems terribly immature imo.
My other major problem with it (the blog post) is that it doesn't pass the timing test. If it was moral and right to share all of this stuff now, why wasn't it moral and right when there was still...
My other major problem with it (the blog post) is that it doesn't pass the timing test. If it was moral and right to share all of this stuff now, why wasn't it moral and right when there was still a salvageable relationship? I can believe for instance all the information is good and true, but if there was some imperative to share it, it shouldn't have been constrained by convenience if you want to claim some kind of principled approach to this stuff.
Shitty behaviour, even if I do in general like zig and Andrew's ideas.
To be fair when I wrote a viral blog post about how terrible a professional relationship went I never named anyone and put in extra effort to make it harder to figure out those details. So in the...
To be fair when I wrote a viral blog post about how terrible a professional relationship went I never named anyone and put in extra effort to make it harder to figure out those details. So in the author’s shoes I’d probably be a little nicer.
If they’re wrong to have shared this then - again - they’re sharing even more with the world than what people normally do. And I appreciate that. Now we have dirt on both parties.
Fair enough! As noted in my previous comment, I suppose I prefer a world with more professional courtesy, but I can understand that the lines between that and "cover-up" can become blurred -- and...
If they’re wrong to have shared this then - again - they’re sharing even more with the world than what people normally do. And I appreciate that. Now we have dirt on both parties.
Fair enough! As noted in my previous comment, I suppose I prefer a world with more professional courtesy, but I can understand that the lines between that and "cover-up" can become blurred -- and given the choice, I'd lean towards preferring openness. I still hope for a world where we can trust one another enough not to speak ill of us behind closed doors, without the threat of NDAs/non-disparagement contracts to keep everyone in line.
I didn’t read the two blog posts about bun (switching to rust and explaining why), but I did read this and it was excellent. This actually gives me more interest in zig again than anything else...
I didn’t read the two blog posts about bun (switching to rust and explaining why), but I did read this and it was excellent. This actually gives me more interest in zig again than anything else has. Not that I was avoiding zig due to bun; the two aren’t and haven’t ever been inexorably linked in my mind. I just like that the creator still cares about his language and is still involved.
Edit: I like it when creators take an interest in their stuff, even if their opinions are strong. It used to be a lot more common for programs and languages to be opinionated about the right way to do things, and I appreciate that. Sometimes being left in the forest of “there’s a thousand ways to do it” is much wiser than “you can do it maybe three different ways” but often times I find it confounding and confusing, and I often prefer the path of “this is how it’s done”… personal preference.
I know very little about the creator of Bun, so I will not comment on anything regarding that, but this stood out to me: What sort of "bigger plans"? They keep pretending that Zig is like the...
I know very little about the creator of Bun, so I will not comment on anything regarding that, but this stood out to me:
His singular focus on productivity and his startup's exit strategy was increasingly at odds with my longer term vision for the Zig project. I remember he kept nagging me to drop all my other priorities and work on a Language Server Protocol implementation and VSCode integration, while I had bigger plans.
What sort of "bigger plans"? They keep pretending that Zig is like the invention of the wheel. A complete joke, when the language is wholly unergonomic and effectively unusable for everyone who isn't actively working on developing it. Zig has been in development for a decade, and Kelly still acts like it's some pilot project in its early stages.
Posts like this are actually infuriating to read due to how holier-than-thou it comes across. I've been a big Zig critic for years and think the language is massively misguided and sells false promises.
Regardless of that, more than anything the surrounding people and general culture make it so repulsive to me. This entire post is insulting and unprofessional, even if it might be partly warranted.
Aparte: For anyone looking for actually usable languages in the same niche, I recommend checking out Odin and C3 instead.
For people interested in Odin or C3 and put off a bit by Zig either because of this post (of which I like), or because of the ergonomics or syntax or instability on zig, here are my thoughts on...
Exemplary
For people interested in Odin or C3 and put off a bit by Zig either because of this post (of which I like), or because of the ergonomics or syntax or instability on zig, here are my thoughts on comparing Odin to Zig. (a lot said about Odin can be applied to C3, I really like C3, and plan on using it a lot more in the future)
I have written a lot of Zig, and a lot a lot of Odin over the past five years, specifically using them as control systems language for motor drivers on robotics. I might be one of the only people do this in any real environment, I have had great experiences, and bad, but overall I enjoyed it more than hated.
Before I say anything about Odin, I have come to learn I really dislike the politics of the Odin creator (he leans a bit too hard to the right for my taste, while every interaction I've had with him is pleasant). Because of his possibly too-far-right-for-my-taste views, I have started to use Odin less and less. It's a small language, a small world, I need to keep some semblance of happiness in my life.
Now, on the language - Odin is far more advanced in many ways compared to Zig where it matters. Odin is incredibly stable, easier to use, has more of 'the things that directly matter' baked into the language. While the std library is written in Odin, and is often even better than the documentation, the documentation is still a little bit missing, and I agree with him that a language should really never become self-hosting, or at the very least waits until it is a major version with non-breaking changes at its core before doing so, unlike Zig that is still making major breaking changes and pushed as fast as possible to become self-hosting.
For Odin, the biggest 'gain' is the ergonomics, the level of which and ability has not been seen in programming in decades - Odin just has much better syntax - Odin's syntax is inspired by Pascal/Oberon/Modula-2 which was designed by Wirth (who I see as a god among language designers, his languages and internal code was pure poetry).
Zig's call to fame was their 'no hidden control flow' but turns out, hidden control flow is what programs do best - to generalize internal structures for easier changing and updates, and the ability to drop down into them is what they should have sought after, similar to Odin, or even C3.
Zig's second call to fame was the way they use general allocators, they weren't the first (hell, every C program I've ever written - that was the first thing I would implement), but they really help popularize it as an alternative to GC, and simplified manual memory management by doing so by having it built right into the core. Odin takes this and expands it, where every context has its *own contextual allocator, making it so you don't even have to think about it - its there, its controllable, every function has a 'hidden' or optional variable declaration to pass or take allocators and set them to the scope, removes a lot of the boilerplate most people never need, that they mess up because its so cumbersome, and it just makes your code look like a right mess. Odin's method of optional, hidden, contextual allocators really helps remove a lot of the boilerplate, and in many cases not even think about memory, until you need or want to.
[ I am personally ignoring their OG call-to-fame, which was comptime, that I actually don't like the implementation of, and can be shoe horned into practically any language in much more ergonomic and less error-prone ways ]
C3 is similar in all of these regards, even if I dislike their C++ inspired Function::Named scheme ;-) Maybe I'll write an Odin-like syntax bridge for C3...
C3 is even nicer in many ways since it's not a revolution, you don't need to create wrappers for C libraries, it just works out of the box. It's a progressive enhancement for C, and it looks nice, feels clean, and light, and just works. They aren't reinventing entire paradigms, everything they do has been done for decades, but they add some nice additions, make the ergonomics as perfect as possible, while still letting users get get get low in the system code. While C3 has an even smaller community compared to Odin, which is even smaller than Zig, which is monumentally smaller compared to Rust, C3 works with any and all C libraries natively, which means pre-written battle tested code is ready for use, for the taking. This is horrible (misleading) phrasing, but C3 is to C, as Typescript is to Javascript. Odin is Pascal for Systems (and games).
I have nothing to add, you phrased it better than I could ever have. I fully agree with absolutely everything you wrote. Thank you for elaborating. These days I find myself writing mostly Odin,...
I have nothing to add, you phrased it better than I could ever have. I fully agree with absolutely everything you wrote.
Thank you for elaborating.
These days I find myself writing mostly Odin, despite finding gingerBill difficult at times. C3 keeps just a tiny bit too much of C to be my go-to language, but it's certainly the second.
I like how based on the framing, you’d think the bun team was about to ask him for some ridiculous feature only they’d care about… And then they actually ask for a language server lmao. Isn’t that...
I like how based on the framing, you’d think the bun team was about to ask him for some ridiculous feature only they’d care about…
And then they actually ask for a language server lmao. Isn’t that tablestakes these days? Does the bun developer expect people to write without any autocomplete?
I would never use Zig for a serious project after reading this blog. It seems like the pet project of an unstable BDFL. People complain that rust is too committee-based, but sometimes you just want the language to get out the way more than anything.
Zig has been pre-1.0 for a decade and I think it’s fine to ignore it until it’s stable. They haven’t even finalized the language yet, let alone the standard library or the tools. Maybe it will be...
Zig has been pre-1.0 for a decade and I think it’s fine to ignore it until it’s stable. They haven’t even finalized the language yet, let alone the standard library or the tools. Maybe it will be good when it’s done, though.
I never used Bun and I don't know much about Jarred Sumner other than reading his recent LLM rewrite posts. I like Zig and Andrew Kelley usually seemed to be a good guy, but I think this blogpost...
I never used Bun and I don't know much about Jarred Sumner other than reading his recent LLM rewrite posts. I like Zig and Andrew Kelley usually seemed to be a good guy, but I think this blogpost is just a poor reckoning with Sumner as a person, and as such is in bad taste and full of immature pettiness.
"Jarred was already writing slop well before he had access to LLMs." feels just like bullying to me. Andrew uses his reach to make fun of a colleague. Why is that ok? Because Sumner is the rich AI guy now? It just sucks.
If he wanted to defend Zig, he could have talked about the technical topics at hand, instead he gossips about Sumner like an ex-girlfriend on Facebook. "I'm sooo glad I got rid of him and his sloppy code."
I use Zig only for hobby gamedev, but I'm not sure I want to be part of the Zig community anymore when its BDFL has so little respect for other people. Just disappointing.
Silicon Valley venture capital dates back to the 1970’s. VC’s funded companies like Intel and Apple. Founders do need to be careful about it, but it’s a weird thing to shame someone for. VC’s...
This attention could have been harnessed in a few different ways. For example, he could have easily achieved a solid living via crowdfunding, even for San Francisco standards. But having graduated from the Thiel Fellowship school of thought rather than university, he was essentially groomed from a young age into uncritically embracing the Silicon Valley mindset, and he took venture capital.
Silicon Valley venture capital dates back to the 1970’s. VC’s funded companies like Intel and Apple. Founders do need to be careful about it, but it’s a weird thing to shame someone for. VC’s aren’t necessarily to blame for a company’s own management problems.
We probably tried to tell you to try enabling it and you didn't listen. We have good advice, damn it!
The word “probably” sticks out here. He can’t remember whether they did or not, didn’t check, and then says they “didn’t listen?”
Two, I actually don't have any personal criticisms of Jarred.
In which case maybe he shouldn’t have posted this, or at least got someone to read it over.
Venture capital is tightly tied to the enshittification pattern that swallowed the entire industry because of the amount of money sloshing around. Everyone just wants growth at all costs in hopes...
Venture capital is tightly tied to the enshittification pattern that swallowed the entire industry because of the amount of money sloshing around. Everyone just wants growth at all costs in hopes of getting bought out and the race to profitability that comes afterwards makes everything worse for users.
That’s a common critique and I think the pursuit of growth and riches is responsible for a lot of problems, including the race to build out AI as fast as possible. But it’s also responsible for a...
That’s a common critique and I think the pursuit of growth and riches is responsible for a lot of problems, including the race to build out AI as fast as possible. But it’s also responsible for a lot of the products and services we use every day. The innovation produced by tech companies isn’t all bad but people choose to dwell on the bad side of it.
Andrew Kelley has updated his conclusion of the post: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html (the 'Moving On' section) Here's the commit on github
Apropos updates, here’s another nice commentary in the form of a third-party/outsider view: https://raymyers.org/post/zed-creator-calls-spade-a-spade/ (It does say zed in the URL instead of Zig,...
Apropos updates, here’s another nice commentary in the form of a third-party/outsider view:
(It does say zed in the URL instead of Zig, not sure whether the author’ll fix that or keep it as it is, but it is about this topic regardless.)
Rather than a real tradeoff comparison, we get a “Bun is better in Rust” section covering only upsides. A change like this always has trade-offs, an obvious one would be build time.
[…]
They also seem to be padding the list by mixing in other improvements they’ve made after the rewrite that aren’t really related to it.
And an interesting section I’m not gonna bother copying in its entirety is under the heading:
They didn’t try a style guide?
(Late edit: wasn’t sure whether this was worth a post of its own when I commented, but (see below) that decision was later made for me anyways. :p)
"Considering a trillion-dollar-company fired the first shot" is I think a little disingenuous when what happened was that Bun was bought by Anthropic, and then switched to Rust as their runtime....
"Considering a trillion-dollar-company fired the first shot" is I think a little disingenuous when what happened was that Bun was bought by Anthropic, and then switched to Rust as their runtime. There were no shots fired here, and I still think this post - regardless of your opinion on the Rust rewrite, which I'm not even particularly opinionated on - is a little childish and reeks of "I could have done so much better if they had just picked ME"
There was a tweet where the bun team announced the rewrite. Implying it was because the Zig team didn't want their compiler improvements because of AI. Which I still believe to be posted in bad faith.
There were no shots fired here
There was a tweet where the bun team announced the rewrite. Implying it was because the Zig team didn't want their compiler improvements because of AI. Which I still believe to be posted in bad faith.
I'm starting to be a bit worried for Kelley. The AI onslaught is not great for people like him, and it's not gonna get better. He (and a lot of other very smart people) seem to be doing the exact...
I'm starting to be a bit worried for Kelley. The AI onslaught is not great for people like him, and it's not gonna get better. He (and a lot of other very smart people) seem to be doing the exact opposite of the famous Bruce Lee adage "be water, my friend".
The AI onslaught hasn't really changed him, he is exactly the same in cadence and tone as he was from the start, if anything he has mellowed out an incredible amount. Just take a look through his...
The AI onslaught hasn't really changed him, he is exactly the same in cadence and tone as he was from the start, if anything he has mellowed out an incredible amount. Just take a look through his blog, this is pretty cordial and I stand by what he said, this makes sense to me and he needed to get in front of it after that Rewrite to Rust article from Bun, which was pretty harsh. The Bun codebase has always been known in the community as surprising that it even ran and could even be massaged into working by anyone since it broke so many standard conventions, and caused many more to be created of what not to do in a codebase at that size and depth.
That being said, Zig is not ready for production even if a few companies somehow took that risk. Their API is always breaking, their syntax is hideous (and I love C), but they do some interesting and novel allocation logic, and their goals are admirable, but they re-invent too many wheels. With this said, I actually admire the overall philosophy that Kelley has about programming, development, community, if anything he is a masterful systems philosopher, and that comes with a fair amount of intensity, I miss this tone and vibe by creators and BDFL in the OSS world, having strong stances and beliefs about your project is vital, not pleasing everyone, just doing what you think is best and standing by it.
[ Removed notes about Odin and C3, moving them to another thread]
I found the post well-written and not abrasive. Bun always seemed like a unnecessary project to this old-school Node developer and the 'rewrite', without this post's context, seemed like an...
I found the post well-written and not abrasive. Bun always seemed like a unnecessary project to this old-school Node developer and the 'rewrite', without this post's context, seemed like an attention-grabbing move.
That's all well and good but why did he link to a Whitest Kids U Know video Edit: I'm going with either A. He's drawing a parallel between sex robot and Claude but how Claude can't be tried and...
That's all well and good but why did he link to a Whitest Kids U Know video
Edit: I'm going with either A. He's drawing a parallel between sex robot and Claude but how Claude can't be tried and hanged or 2. Video ends on "what did we learn here today?", which he may be responding to with a shrug? We must go deeper
Andrew is seemingly grateful for Buns departure.
What a read lol. I'm a little surprised by the overall tone of the blog post.
I'm not. Andrew Kelley's blog posts often have blunt and/or abrasive language. To the point where the discussion of his writing is often sidelined by talk of how uncouth it is.
The instance that comes to mind was his post discussing Zig's move away from GitHub, that had some language that was so abrasive that it went through multiple editing passes after publishing.
- https://news.ycombinator.com/item?id=46133179
Some people think they can get away with being as abrasive or more so than Linus Torvalds but with none of the prestige or tact.
Linus has prestige but I don’t know if I’d say he has tact.
I really enjoyed the read, kind of felt honest and still reasonably kind while at the same time not really holding back too much.
It was a great read, thanks for posting. I dabbled in Zig some time back on a journey to familiarise myself with a bunch of the "new" languages on the block. Zig, Rust, Go, Chef, that sort of thing. I can't think I'll have an actual real world use case for it though.
I do read / hear / watch a lot of stories about AI contributions to FOSS projects though, both direct contributions and bug reports, and almost none of it is positive.
Holy crap, I'm never touching Zig or Bun with a ten foot pole. What a bunch of unprofessional jerks.
So what they're saying is, if I use their obscure language and ask for help (or even donate!) -- then dare criticise them -- they'll whip out the call logs to start railing me in the socials? What the heck?
Bun always gave me the ick, and Zig felt like a solution in search of a problem. I've had the privilege of working with genuine professionals: they could wipe the floor with me engineering-wise, and were level headed when the seas became rough. But these guys ain't it. They really deserved each other.
Ehhh given the context of the Bun author posting a blog making potentially false claims about the language I do think Zig gets to defend themselves.
If they just dropped this after Bun moved to Rust it’d be bullshit but given they straight up said “oh yeah zig just can’t scale we were doing it right” I think you get to counter, especially if you have reason to believe it’s a blatant lie.
I am curious what all the fallout from this will be. It strikes me that both sides have objectively provable claims(either zig doesn’t scale well in buns case or bun had slop code) so it shouldn’t be that hard to point to “like this line here” but so far there’s a lack of that
I ... guess? I suppose I'm used to e.g. Bjarne Stroustrup not coming out swinging whenever someone bails on C++ for, like, D or something. Or I guess Oracle dropping a diss track for every press release praising Kotlin. And there doesn't seem to be animosity between the Kotlin and Dart crews.
If someone stops using your project then great, more power to them. If they misunderstood the assignment, and had been misusing your tool the whole time, then I guess that's on them. The need to "well ackshually" every critique leveled against your project via competing open letters is a trend that I've grown to despise in the modern software development community.
I'm probably just being nostalgic for the bygone days of yore, where the people engaging in the language wars were just us sweaty code monkeys, swinging away in the pits. It's very odd to see this sort of poop slinging being done by the ostensible responsible adults in the room.
I don't think those are objectively provable? I can jump into nearly any codebase and find regrettable choices, especially once they crack the mid-five digits. Similarly, you can find C++ projects pushing several hundred thousand lines which compile faster than mid-sized Rust projects, because the people architecting them understand how to leverage their (admittedly, distributed and caching 😅) compiler toolchains extremely well. So ... everything can scale. And everything can be written poorly. IMO at least.
Comparing programming languages is super difficult, which is why I've historically selected them based primarily on what I know about the teams that're going to support them. I'd choose a vanilla TS/JS project ten out of ten times if I knew the crew that was running it was allergic to Kotlin Jetpack, but if the app devs needed to stretch their wings out into a small web service, I'd lean towards the tool they already know.
(edit) Sorry; I let this go unstated in my original message, but to note it: I'm aware that this is a marketing stunt done by some egotistical jerks manipulating their respective communities into donating their time, money, or mindshare. That's just the core of what's disappointing here.
On the other side though this is a big issue. If multiple people come out and just say "yeah zig doesn't scale" that's a problem, and a major project is a very loud datapoint on that.
We know the weaknesses of languages like C/Java/JS/Etc, but with newer languages the more they're tested the more we learn.
Even ignoring the money in the room, this is how coders have discussed this stuff. Linus is not known for his private beatdowns, it just wasn't as visible because you had to be a linux kernal dev or interested in that to even see it. It had similar ramifications though in that the outcomes of those shit slinging sessions often would determine major standards and tech adoption.
When everyone swears their product is the best (again nothing really new, just inflated thanks to the money) getting valid data points is important, and if you just hear "oh wow Zig just can't handle catching some memory errors while rust can" that's a BIG statement given that is probably one of THE largest problems in coding and any tool in this day and age not solving it leads you back to "might as well use C, at least I can hire for it" or similar problems.
Depends. Both sides could be providing code snippets they thought were unreasonable. It's not some awkward "well in this environment" performance metric which can be bullet proof or wildly variable. Both posts would be a lot more powerful with a "For example" code block of what they thought was being done right or wrong. If it's as egregious as they're both claiming (one migrating to a new lang, one saying they write out and out slop) that should be fairly easy to identify.
Yes if the answer is "well we have some slop, we all do" that's trickier, but we don't even have a starting point for reference to judge that.
IMO, understanding where tools have fallen short doesn't make them good or bad on a flat, 1d spectrum, it just indicates where the risks could be in adoption. Even if it can't "scale" (for however the term is being used in this case), that still doesn't remove its other proven benefits. Bun's post on this is extremely verbose, but IMO since every tool has a set of tradeoffs associated with it, it's still very informative: not everyone is the literal creator of Zig and capable of writing pristine code.
If we were actually doing software engineering, the takeaway from viewing a failure would not be "oh no this whole thing is bad! We'll never use any of these tools!", it would be understanding the root causes of those issues in order to better develop plans to avoid them, since all tools have flaws and nothing is perfect. Analogously: just because a house catches fire once doesn't mean we should stop building houses and return to the caves -- which are clearly the superior form of housing, since they don't catch fire!! -- because everything is a tradeoff. People like having walls, and windows, and etc. So the takeaway should be to install fire sprinklers, or AFCIs, not to discard an entire toolchain because someone rich and super smart wrote some blogspam about how they've abandoned the surface world. The weird, uncritical, cargo cultness of software development really irks me.
But that's a subtle point. I think people love the language benchmark game or the TIOBE index since they provide a clear and unambiguous ranking of an otherwise complicated problem, which -- ultimately -- generally has little to no impact on your team's ability to execute on a given project. Given the number of projects barely limping on with extraordinarily subpar stacks in the world (lord knows I've seen enough of them), we have existence proofs that one can accomplish basically everything with anything these days, delta some realtime-critical applications.
Quick sidebar: it can't though, can it? Zig doesn't appear to have a borrow checker, and from a skim, it doesn't have a GC either (or ARC). Assuming you were thinking of memory leaks when you mentioned errors? (and not, like, use-after-free, array bounds checking, or etc.) Also also we kinda solved this with garbage collection a couple decades ago; for whatever reason, marketing teams have successfully unsolved it for many folks, but I've very rarely seen GC behaviour cause an issue under load where there wasn't some underlying problem (e.g. memory leaks in unmanaged pools, or some algorithmic error which would've thrashed a manual allocator anyhow).
I fundamentally don't understand what quoting snippets at each other would do in this case, though. Like, is the goal to learn what went wrong, so we can do better as an industry? It really feels like petty squabbling.
Just addressing this separately, but imo Linux isn't a great example: languages are a dime a dozen (Zig is an uncomfortable middle child between golang, Rust, and C++), and they can be swapped out pretty easily and without major consequence. If one project catches fire and explodes, sure, fine, do a rewrite and move on.
If the Linux project went down -- especially for a critical decade or two in there -- I'm not sure another project could've taken up the reigns? Sure we have some weird nix's in there (GUIX, Solaris, ... Darwin (_shudders)) ...), but they weren't anywhere near as mature or multipurpose. Linux can work on anything from your microwave to a car to a supercomputer, which would've been extremely challenging to reproduce in another OS.
I don't know what it would even mean if Linux "went down." If some controversy happened, the various Linux distributions and tech companies that use the Linux kernel could start up a new fork pretty quick, like Redis / Valkey.
Ah, apologies, I should've been more precise. The context of this discussion is comparing Linus' jackassery to Andrew's, with respect to defending the honour of their respective OSS projects. I'm claiming that a broad drop in confidence in Zig's ability to perform as a programming language is orders of magnitude less important to the software development community as a whole than Linux's. I don't feel that either maintainer's response is appropriate, but since there are actual stakes at play if the industry as a whole decides to move on from Linux because someone powerful dictates that "it can't scale" or something, it doesn't seem like an apt comparison.
Taken to its logical extremes, if we accept that toddlers can cry because they can't have juice after bedtime, does that justify Andrew throwing a tantrum because a donor pulled out?
No i'm definitely summarizing and essentially agree, but I've met the kind of people who thought everything should be made with JS (before TS even existed), and I think seeing a language in the wild/reality is important. Things that don't matter for one scope matter a LOT for another, and given "will i need to manually handle memory" is one of the biggest decisions at the product creation, Zig's performance there on a major product strikes me as very very important.
It cannot, and neither can rust fully catch them. To quote the Bun dev (search for Jarred. I can't link directly to a comment sadly):
So:
Because it's proof of reality so we can learn what went wrong? I don't just ask my team "what do you think went wrong?". I often want to see it so I can discuss if it was a reasonable mistake or a footgun they need to watch out for.
For the record this blog's claim that they "outright lied" has been countered with this comment (same as above but I think its the top comment?). Now I don't have enough expertise to know if that's a real counter or not, and it sure seems like there's still plenty of back and forth discussion on it on if this is relevant or just "well yeah right before you ported you started fuzzing". At least it's a valid and provable data point though for someone trying to consider if the claims being made are real.
A random blog writeup that is inherently biased (in both cases) strikes me as a less than useful datapoint. Git activity and actual code gives plenty of real examples to dive into to at least asses "oh god Zig will be a minefield of gotcha's" or "jesus no wonder Bun is whining, this code is crap".
I mean...I still think it holds. Linus is not an outlier in behavior. It's not really a secret that coding has attracted some difficult personalities who like to wave it around. Jobs is more "tech" and was hardly timid and more specific to me the lead datastar dev strikes me as his own worst enemy. Lot more "Jobs" than "wozniak" heading most of these projects, and it always has been. It's just more front and center now.
Aaaaugh HN. I hoped never to see that orange banner again. I think you're linking to this comment? You can get a direct link by clicking the "X days ago" text.
Agreed re. JS. People've been zealots for their favourite tools forever. But it's disappointing to me that a debate akin to Milwaukee vs. Dewalt seems to be elevated to the level of pseudoscience (pseudoengineering?) in software dev circles, whereas -- afaict -- tradesfolk are generally not actually frothing at the mouth crazy when they defend their preferred power tool colour. Dunno, maybe people with more experience can chime in; I only have Reddit comments to rely on.
Yep. Not sure where the framing of my claim that Rust fully solves "them" came from. Your full statement was:
My response was that it is provably the case that Zig can't handle some memory errors while Rust can. I was not making a universal statement, so I'm not sure why I'm being framed as having done so.
Ah, that's on me; I added a statement in out-of-sequence in a previous paragraph to couch my claim:
High frequency trading, aerospace, or nuclear control systems, all of which have liveness and realtime constraints which a GC generally cannot meet. Please note, though, that the statistically average professional software developer is writing with a language that would be a PIA to extract the GC from (Stack Overflow 2024 Survey; to my eye, maybe 15% -- optimistically -- used Rust/C++/C that year) so evidence strongly leans towards the observation that GCs must have solved a huge section of these problems for the overwhelming majority of situations. Either that, or 85% of programs don't have this problem to begin with, so we're back to saying it's only a minority concern.
Please understand that I am not stating that every memory-related software defect can be addressed with a GC. I am stating that a GC fixes the problems that a GC fixes, that Rust's borrow checker fixes what Rust's borrow checker fixes, and Zig's arena allocators (iirc that's how it handles memory allocation) fix what Zig's arena allocators fix. These all correspond to addressing a not-necessarily-overlapping set of defects in applications. The claim I made was that there are a large set of memory use-related errors that Rust prohibits at compile time (when using the borrow checker properly) which Zig will not (without excessive hoop jumping).
Re. Bun and the necessity of garbage collection, all I can point to are Maven, Gradle, Bazel, and all the existing Javascript tooling to say that they didn't need to abandon the GC to hit whatever their performance goals are unless they're extremely memory constrained for some reason. Bazel especially rips through enormous builds by dint of running a persistent build daemon. To be precise about my point: "performance" is squirrelly and ill-defined. We have evidence that, for some definition of "performant", we can build performant build systems that use GCs.
I think we're in agreement? I'm once again being bitten by my terrible communication skills. I was trying to imply that a third party's coherent, low bias analysis of the problem is what's necessary for coming to any reasonable conclusion. When each side slings isolated fragments of evidence at one another, we lose the context, distribution, and frequency information which is critical for understanding if they're e.g. cherry picking in order to "win" the debate.
Pretty much agreed.
On the contrary, Rust has Bjarne panicking that C++ is being attacked.
Ach, good find. It looks like his original letter is from ~2023, so this isn't a recent thing either. Sigh.
Assuming it's true, I think it's entirely reasonable to share this with the world. I wish more people participated in free exchange of information like this. Far too much is held back out of politeness leaving people ignorant.
The blog post amounts to "He's got what he wants, his project is no longer my burden, oh and this bit was a lie". It's the kind of professionalism I think Silicon Valley needs more of. For example, I've met a founder in SF who I'm pretty sure is a sociopath. I heard him say some wild stuff about his employees. I wish I could share that stuff with the world to alert people in advanced, but I don't really have the means.
Strong disagree. They're acting like consultants in this scenario: a fee is paid to their organization so that they'll listen to your concerns, and then provide advice on how to fix them. We truly should not create the norm that consultants leak your dirty laundry: the entire point is that you can be fully open with them, but if you need to hold information back for fear of their badmouthing you later, then the entire relationship is soured.
To be clear: I'm not talking about actually important things, like exposing SA or whatnot. This is just business. When two groups of people speak with the expectation of privacy, violating that trust is a bridge you can't uncross.
Mmhm, and same. But that's very different than trashing someone's reputation given your insider knowledge because they've broken ties.
I dunno; I get that people want others to be more open in general, but this feels like if your doctor started a blog describing how much of a piece of crap their patients in particular are, and called them out by name. It seems terribly immature imo.
My other major problem with it (the blog post) is that it doesn't pass the timing test. If it was moral and right to share all of this stuff now, why wasn't it moral and right when there was still a salvageable relationship? I can believe for instance all the information is good and true, but if there was some imperative to share it, it shouldn't have been constrained by convenience if you want to claim some kind of principled approach to this stuff.
Shitty behaviour, even if I do in general like zig and Andrew's ideas.
To be fair when I wrote a viral blog post about how terrible a professional relationship went I never named anyone and put in extra effort to make it harder to figure out those details. So in the author’s shoes I’d probably be a little nicer.
If they’re wrong to have shared this then - again - they’re sharing even more with the world than what people normally do. And I appreciate that. Now we have dirt on both parties.
Fair enough! As noted in my previous comment, I suppose I prefer a world with more professional courtesy, but I can understand that the lines between that and "cover-up" can become blurred -- and given the choice, I'd lean towards preferring openness. I still hope for a world where we can trust one another enough not to speak ill of us behind closed doors, without the threat of NDAs/non-disparagement contracts to keep everyone in line.
I didn’t read the two blog posts about bun (switching to rust and explaining why), but I did read this and it was excellent. This actually gives me more interest in zig again than anything else has. Not that I was avoiding zig due to bun; the two aren’t and haven’t ever been inexorably linked in my mind. I just like that the creator still cares about his language and is still involved.
Edit: I like it when creators take an interest in their stuff, even if their opinions are strong. It used to be a lot more common for programs and languages to be opinionated about the right way to do things, and I appreciate that. Sometimes being left in the forest of “there’s a thousand ways to do it” is much wiser than “you can do it maybe three different ways” but often times I find it confounding and confusing, and I often prefer the path of “this is how it’s done”… personal preference.
I know very little about the creator of Bun, so I will not comment on anything regarding that, but this stood out to me:
What sort of "bigger plans"? They keep pretending that Zig is like the invention of the wheel. A complete joke, when the language is wholly unergonomic and effectively unusable for everyone who isn't actively working on developing it. Zig has been in development for a decade, and Kelly still acts like it's some pilot project in its early stages.
Posts like this are actually infuriating to read due to how holier-than-thou it comes across. I've been a big Zig critic for years and think the language is massively misguided and sells false promises.
Regardless of that, more than anything the surrounding people and general culture make it so repulsive to me. This entire post is insulting and unprofessional, even if it might be partly warranted.
Aparte: For anyone looking for actually usable languages in the same niche, I recommend checking out Odin and C3 instead.
For people interested in Odin or C3 and put off a bit by Zig either because of this post (of which I like), or because of the ergonomics or syntax or instability on zig, here are my thoughts on comparing Odin to Zig. (a lot said about Odin can be applied to C3, I really like C3, and plan on using it a lot more in the future)
I have written a lot of Zig, and a lot a lot of Odin over the past five years, specifically using them as control systems language for motor drivers on robotics. I might be one of the only people do this in any real environment, I have had great experiences, and bad, but overall I enjoyed it more than hated.
Before I say anything about Odin, I have come to learn I really dislike the politics of the Odin creator (he leans a bit too hard to the right for my taste, while every interaction I've had with him is pleasant). Because of his possibly too-far-right-for-my-taste views, I have started to use Odin less and less. It's a small language, a small world, I need to keep some semblance of happiness in my life.
Now, on the language - Odin is far more advanced in many ways compared to Zig where it matters. Odin is incredibly stable, easier to use, has more of 'the things that directly matter' baked into the language. While the std library is written in Odin, and is often even better than the documentation, the documentation is still a little bit missing, and I agree with him that a language should really never become self-hosting, or at the very least waits until it is a major version with non-breaking changes at its core before doing so, unlike Zig that is still making major breaking changes and pushed as fast as possible to become self-hosting.
For Odin, the biggest 'gain' is the ergonomics, the level of which and ability has not been seen in programming in decades - Odin just has much better syntax - Odin's syntax is inspired by Pascal/Oberon/Modula-2 which was designed by Wirth (who I see as a god among language designers, his languages and internal code was pure poetry).
Zig's call to fame was their 'no hidden control flow' but turns out, hidden control flow is what programs do best - to generalize internal structures for easier changing and updates, and the ability to drop down into them is what they should have sought after, similar to Odin, or even C3.
Zig's second call to fame was the way they use general allocators, they weren't the first (hell, every C program I've ever written - that was the first thing I would implement), but they really help popularize it as an alternative to GC, and simplified manual memory management by doing so by having it built right into the core. Odin takes this and expands it, where every context has its *own contextual allocator, making it so you don't even have to think about it - its there, its controllable, every function has a 'hidden' or optional variable declaration to pass or take allocators and set them to the scope, removes a lot of the boilerplate most people never need, that they mess up because its so cumbersome, and it just makes your code look like a right mess. Odin's method of optional, hidden, contextual allocators really helps remove a lot of the boilerplate, and in many cases not even think about memory, until you need or want to.
[ I am personally ignoring their OG call-to-fame, which was comptime, that I actually don't like the implementation of, and can be shoe horned into practically any language in much more ergonomic and less error-prone ways ]
C3 is similar in all of these regards, even if I dislike their C++ inspired Function::Named scheme ;-) Maybe I'll write an Odin-like syntax bridge for C3...
C3 is even nicer in many ways since it's not a revolution, you don't need to create wrappers for C libraries, it just works out of the box. It's a progressive enhancement for C, and it looks nice, feels clean, and light, and just works. They aren't reinventing entire paradigms, everything they do has been done for decades, but they add some nice additions, make the ergonomics as perfect as possible, while still letting users get get get low in the system code. While C3 has an even smaller community compared to Odin, which is even smaller than Zig, which is monumentally smaller compared to Rust, C3 works with any and all C libraries natively, which means pre-written battle tested code is ready for use, for the taking. This is horrible (misleading) phrasing, but C3 is to C, as Typescript is to Javascript. Odin is Pascal for Systems (and games).
I have nothing to add, you phrased it better than I could ever have. I fully agree with absolutely everything you wrote.
Thank you for elaborating.
These days I find myself writing mostly Odin, despite finding gingerBill difficult at times. C3 keeps just a tiny bit too much of C to be my go-to language, but it's certainly the second.
I like how based on the framing, you’d think the bun team was about to ask him for some ridiculous feature only they’d care about…
And then they actually ask for a language server lmao. Isn’t that tablestakes these days? Does the bun developer expect people to write without any autocomplete?
I would never use Zig for a serious project after reading this blog. It seems like the pet project of an unstable BDFL. People complain that rust is too committee-based, but sometimes you just want the language to get out the way more than anything.
Zig has been pre-1.0 for a decade and I think it’s fine to ignore it until it’s stable. They haven’t even finalized the language yet, let alone the standard library or the tools. Maybe it will be good when it’s done, though.
I never used Bun and I don't know much about Jarred Sumner other than reading his recent LLM rewrite posts. I like Zig and Andrew Kelley usually seemed to be a good guy, but I think this blogpost is just a poor reckoning with Sumner as a person, and as such is in bad taste and full of immature pettiness.
"Jarred was already writing slop well before he had access to LLMs." feels just like bullying to me. Andrew uses his reach to make fun of a colleague. Why is that ok? Because Sumner is the rich AI guy now? It just sucks.
If he wanted to defend Zig, he could have talked about the technical topics at hand, instead he gossips about Sumner like an ex-girlfriend on Facebook. "I'm sooo glad I got rid of him and his sloppy code."
I use Zig only for hobby gamedev, but I'm not sure I want to be part of the Zig community anymore when its BDFL has so little respect for other people. Just disappointing.
Silicon Valley venture capital dates back to the 1970’s. VC’s funded companies like Intel and Apple. Founders do need to be careful about it, but it’s a weird thing to shame someone for. VC’s aren’t necessarily to blame for a company’s own management problems.
The word “probably” sticks out here. He can’t remember whether they did or not, didn’t check, and then says they “didn’t listen?”
In which case maybe he shouldn’t have posted this, or at least got someone to read it over.
Venture capital is tightly tied to the enshittification pattern that swallowed the entire industry because of the amount of money sloshing around. Everyone just wants growth at all costs in hopes of getting bought out and the race to profitability that comes afterwards makes everything worse for users.
That’s a common critique and I think the pursuit of growth and riches is responsible for a lot of problems, including the race to build out AI as fast as possible. But it’s also responsible for a lot of the products and services we use every day. The innovation produced by tech companies isn’t all bad but people choose to dwell on the bad side of it.
Andrew Kelley has updated his conclusion of the post: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html (the 'Moving On' section)
Here's the commit on github
Apropos updates, here’s another nice commentary in the form of a third-party/outsider view:
https://raymyers.org/post/zed-creator-calls-spade-a-spade/
(It does say
zedin the URL instead of Zig, not sure whether the author’ll fix that or keep it as it is, but it is about this topic regardless.)[…]
And an interesting section I’m not gonna bother copying in its entirety is under the heading:
(Late edit: wasn’t sure whether this was worth a post of its own when I commented, but (see below) that decision was later made for me anyways. :p)
Corresponding Tildes discussion:
https://tildes.net/~comp/1v3m/zig_creator_calls_spade_a_spade_anthropic_blows_smoke
Thanks for the update. I think he handled the response to his blog post quite gracefully.
"Considering a trillion-dollar-company fired the first shot" is I think a little disingenuous when what happened was that Bun was bought by Anthropic, and then switched to Rust as their runtime. There were no shots fired here, and I still think this post - regardless of your opinion on the Rust rewrite, which I'm not even particularly opinionated on - is a little childish and reeks of "I could have done so much better if they had just picked ME"
There was a tweet where the bun team announced the rewrite. Implying it was because the Zig team didn't want their compiler improvements because of AI. Which I still believe to be posted in bad faith.
I'm starting to be a bit worried for Kelley. The AI onslaught is not great for people like him, and it's not gonna get better. He (and a lot of other very smart people) seem to be doing the exact opposite of the famous Bruce Lee adage "be water, my friend".
The AI onslaught hasn't really changed him, he is exactly the same in cadence and tone as he was from the start, if anything he has mellowed out an incredible amount. Just take a look through his blog, this is pretty cordial and I stand by what he said, this makes sense to me and he needed to get in front of it after that Rewrite to Rust article from Bun, which was pretty harsh. The Bun codebase has always been known in the community as surprising that it even ran and could even be massaged into working by anyone since it broke so many standard conventions, and caused many more to be created of what not to do in a codebase at that size and depth.
That being said, Zig is not ready for production even if a few companies somehow took that risk. Their API is always breaking, their syntax is hideous (and I love C), but they do some interesting and novel allocation logic, and their goals are admirable, but they re-invent too many wheels. With this said, I actually admire the overall philosophy that Kelley has about programming, development, community, if anything he is a masterful systems philosopher, and that comes with a fair amount of intensity, I miss this tone and vibe by creators and BDFL in the OSS world, having strong stances and beliefs about your project is vital, not pleasing everyone, just doing what you think is best and standing by it.
[ Removed notes about Odin and C3, moving them to another thread]
I found the post well-written and not abrasive. Bun always seemed like a unnecessary project to this old-school Node developer and the 'rewrite', without this post's context, seemed like an attention-grabbing move.
That's all well and good but why did he link to a Whitest Kids U Know video
Edit: I'm going with either A. He's drawing a parallel between sex robot and Claude but how Claude can't be tried and hanged or 2. Video ends on "what did we learn here today?", which he may be responding to with a shrug? We must go deeper
¯\_(ツ)_/¯