While I agree that the Zig code in Bun could be better, and that the Silicon Valley pressure to move fast and break things prevented a lot of suggested improvements, this feels like the same argument as people who write C or C++ where people think they wouldn’t make mistakes.
For example this section
> We've been trying to warn you about your comptime abuse for years.
You could replace comptime with templates in C++ and it would be the same story. People will abuse features you put in the language. Is C++ a good language that people are just using wrong? According to Bjarne Stroustrup yes, and the C++ core guidelines fixes those issues, but a lot of people seem to disagree. Don't believe me here is an interview where he talks about memory safety in C++? ^1
> Ryan: One thing that I think C++ is uh infamous for is kind of like memory safety issues or kind of foot guns that exist there.
> Bjarne: I'm so tired of that. Um I haven't had those problems for years. Um, and somebody did a a study of the obvious problems with buffer overflows and um people hacking in using that kind of stuff and uh almost all of the uh these cases when people writing C style code or in C and uh Herb Server has a a talk with with actual numbers and they they are quite significant. It's it's sort of that kind of problems more than 90% are for people that don't write modern C++. They they use raw pointers to pass things around without um the number of elements. No fat pointers, no spans. um you you have them in C++. You can use them. You can use uh vectors. We have hardened libraries. Everybody has hardened libraries that that does the runtime checking. Uh Apple has it. Google has it. Microsoft has it. It's just not standard till now. C++ 26 has a hardened option that are standard. uh and the work I'm doing on profiles will give you a way of guaranteeing that you don't do the stupid things. Um so anyway, uh fundamentally theoretically the problem was solved many years ago and people just do what they've always done and get the problems they've always had. And uh that makes me sad and uh it's one of the things that makes me work on uh coding guidelines and on enforced profiles and on education. I mean education is one way to solve the problem. Is there a way to get the compiler to just prevent people from doing all those risky things? And is that enabled by default in modern C++ today? No, but it should be. I'm proposing that for C++ 29. Uh the simpler versions of that should have been in in in uh C++ 26, but there are still a lot of people even in the C++ standards committee that are very devoted to uh their old code and their old ways of doing things. Um there's people who says you should only standardize what is common in industry. But when the bugs are common in industry, you should do something else.
Is this going to be Zig's answers to real issues that people have in the real world? I'd argue that's not good enough for a modern systems programming language.
> We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt.
The vast majority of software is written by businesses, who have to cater to the lowest common denominator in their code base, including slop programmers, pre or post llm. They are not incentivized to go slower. We will never see a mass adoption of Tiger Style programming (though I would be happy to be proven wrong). That is the reality of what we need programming languages to help with in 2026. I've never met a professional programmer that has not seen or said the same thing about a code base that they've worked on.
New programming languages need to contend with that reality if they want to be adopted en masse. If not they are doomed to not be adopted (which is okay I've created many programming languages that are just for me). But if a programming language in never adopted then the supposed benefits or improvements of the language never trickle down to us the users of the software, so they just remain interesting ideas (which again is okay).
> 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.
Andrew kelley runs a tight ship, and his foundation does not need a lot of money to keep going, but he has talked about how working on all the organizational transparency is not his favorite part of the project, and I can see why a lot of young programmers wouldn’t want to go that way.
Now let me be clear I actually like Zig, and have promoted it on Hacker News before, and written some code myself. I actual uses Zigcc in one of my projects because it makes my life easier. I genuinely love the tooling of Zig, and I feel like the language respects my time. I want the language to succeed
I also think that Andrew Kelley is a principled man with good engineering sense, and has turned down opportunities that would have made him a lot more money, were he to violate his own principles. That is admirable, and he has demonstrated it on so many occasions that it is currently not a question to me. What I would like to see, and what Andrew has said Zig focuses is how Zig can improve program correctness even more, without requiring me, or my coworkers to be a 10x programmer
It’s interesting to see how llms have turned the concept of rewrite it in rust, from an impossibility for some projects (code is too large and complicated, it will take too much time) to a real possibility for even large projects.
I'm curious to hear from people if anyone who uses Bun after this changed has noticed any day to day differences with the rust version over the zig version
I wonder how useful this could be as a generalized version control for regular user systems, as a way to rollback, or scrub through history. Presumably if this is designed to work at Epic and Big Game studio scale, it should work at home computer scale
and Ryan asked Bjarne about memory safety. Bjarne brushes it off and says that in almost all cases where we see memory safety issues, they are either
1. Being written in C style C++ and not using "Modern C++"
2. Being written in C
He then goes on to say say that Modern C++ and where it is necessary, hardened libraries, go a long way to making these problems non issues. I'm not a C++ guy, so how much of this is true? What do the C++ developers think about this?
I've postd the whole message if people would like to read. It's about 46minutes into the video
Ryan: One thing that I think C++ is uh infamous for is kind of like memory safety issues or kind of foot guns that
exist there.
Bjarne:
I'm so tired of that. Um I haven't had those problems for years. Um, and
somebody did a a study of the obvious problems with buffer
overflows and um people hacking in using that kind of
stuff and uh almost all of the uh these cases when
people writing C style code or in C and uh Herb Server has a a talk with
with actual numbers and they they are quite significant. It's it's sort of
that kind of problems more than 90% are for people that don't
write modern C++. They they use raw pointers to pass
things around without um the number of elements. No fat pointers, no spans.
um you you have them in C++. You can use them. You can use uh vectors. We have
hardened libraries. Everybody has hardened libraries that that does the runtime checking. Uh Apple has it.
Google has it. Microsoft has it. It's just not standard till now. C++ 26 has a
hardened option that are standard. uh and the work I'm doing on profiles will
give you a way of guaranteeing that you don't do the stupid things.
Um so anyway, uh fundamentally
theoretically the problem was solved many years ago and people just do what
they've always done and get the problems they've always had. And uh that makes me
sad and uh it's one of the things that makes me work on uh coding guidelines
and on enforced profiles and on education. I mean education is one way to solve the
problem. Is there a way to get the compiler to just prevent people from
doing all those risky things? And is that enabled by default in modern C++ today?
No, but it should be. I'm proposing that for C++ 29. Uh the simpler versions of
that should have been in in in uh C++ 26, but there are still a lot of people
even in the C++ standards committee that are very devoted to uh their old code
and their old ways of doing things. Um there's people who says you should only
standardize what is common in industry. But when the bugs are common in
industry, you should do something else. The standards committee is a a topic I
For clarity in this dual programming language scenario I'm talking about, I'm writing a user facing app that's mostly a lot of business logic.
It's running slow so I profile it and I see my math function in pure Dart (or whatever language you are writing in) is the hot spot, and pressures the garbage collector too much, so I rewrite the function in a lower level language that doesn't have as much overhead, to speed things up. Then I just call it from the higher level language through the FFI.
The benefit of Zig is the syntax is simple, and the build steps are simple, so it doesn't slow down app development too much
I mean as an avid Lisp fan, I feel like Lisp basically answers the question of how much syntax you need in a langauge. I must admit though, not having to deal with operators precedence is really nice
Here is where I think Zig shines. When you are a high level programmer that needs to drop down to a low level programming language for performance reasons. The issue with doing that as a high level programmer is that you don't do a lot of low level work frequently.
So unless you work in another domain where you do a lot of low level programming, then every time you drop down you will be out of practice. This favors using a simpler low level language, with low friction for integration. Rust and C++ don't handle being used infrequently, but C with it's simpler standard library and syntax fits this nicely. But it doesn't have things you expect for a modern programming language, and it is also has a lot of dangerous footguns that are easy to forget if you are out of practice
In comes Zig. It's low level, comes with it's own toolchain that makes it pleasant to work with, easy to cross compile, has more safety features built in that C, but is not overly complicated. The code tends to be more verbose, but also more straightforward. So it's a perfect language to pair, when you know you won't be able to do everything in a high level language.
For me that's what seals the deal. I'd argue that Odin has a nicer syntax, but there is a reason that tools like cargo-zigbuild^1 exists. The fact projects not related to Zig are willing to ship Zig toolchains to make lives easier is a testament to how seriously Zig takes this.
I am not 100% opposed to AI and I spent multi hundreds of dollars across the major players right now, but I'll see what I can add.
> At some point, execution speed starts to matter more than the elegance of the code.
This sentiment has been with us for a long time, and AI has only made it worse. Many people have experienced the damaging effects that focusing on execution speed have had on our lives, and you would think if AI makes us 10x faster, we could spend half that time actually making programs more performant and secure. But all of the gains always funnel into speed, when we have the golden opportunity to make things better.
Then there are the players that make it. Casey Muratori recently did a video called "It just Happened" where Eric Schmidt gives a commencement speech and washes his hands of the negative things that have happened in it, even though his decisions at Google and the technology he helped create made a lot of that happen. A quote from Casey's Video
> This is a case where someone who had direct decision-making authority during the time period when the very worst most dystopian parts of the technology business model were developed, perfected and entrenched. And he is giving this commencement speech to a group of students who have known nothing but that their whole lives. They're not like me. They didn't know a time before all of this. They didn't experience technology in the 80s or something like this.
One of the most important things in that quote is that there are people who have known nothing but a predatory, privacy invasive technology world. When that is your baseline, new technology that could advance that at 10x speed does not feel great. And now it requires only a couple bad actors and a subscription to make that happen.
At work we are mandated to use AI. That feels bad for a lot of reasons. But one of the worse is having to review AI generated code. I have never liked reviewing other peoples PRs, and now with the speed AI code is created, I could spend the whole day just doing that. So now my job is worse because I have to do more of the part I like the least.
Next, I've been thinking a lot about "the human scale of things". To me that means slowing down, and not consuming things faster than my lizard brain can understand. While I might be able to go 10x faster, unless I'm doing something I've done a million times before, I will not be able to keep that much code in my head. So I quickly lose understandings of projects, and I have to fight hard to rebuild my knowledge.
Lastly, as someone who has "vibecoded" an app, It feels completely impersonal. Yea I had the idea, and yea I had to type the prompts, but producing a whole mountain of code over the course of weeks or months (I've done both) just leaves me feeling empty on the inside. There is still a selfish human component to the programming that I and I suspect others do, and AI takes away from that
I'm not sure what the solution is though. Do we say, if you don't want to take ownership over the bad things that happen then we will down play your part in the good? Do we try to set up organizations that persecute those accountable? Should Eric Schmidt be in jail? Should he be fined? Do we as developers try to use the tools "for good?" I don't know, and I'd love to know what other people have to say on this
In Grad school I remember learning Python 2, and there was one particular night where an assignment of mine just wasn’t working and no searches were helping me. I was frustrated to the point of tears, and when I solved it, it wasn’t with some triumphant yell. I just remember being so tired, closing my laptop and going to sleep.
I’m sure I wouldn’t be the programmer I am without that experience, but I am Not sure I would have willingly put myself through that if LLMs existed at that point
There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low level programming language really well, you'll most likely have to re familiarize yourself with the language before doing the low level stuff.
This makes Cpp and Rust harder to use then say C, so C becomes the default for me. But C is not without its issues of which we are aware. But Zig feels like it could fill that sweet spot really well, being simple enough that it's easier to pick up after a long break, but still coming with a lot of modern tooling that makes programming easier.
I really appreciate Casey for making this video. The two quotes that stand out to me are
> This is a case where someone who had direct decision-making authority during
the time period when the very worst most dystopian parts of the technology
business model were developed, perfected and entrenched.
And he is giving this commencement speech to a group of students who have known nothing but that their whole
lives. They're not like me. They didn't know a time before all of this. They didn't experience technology in the 80s or something like this.
I think this is hugely important context. New technologies are not being built in a vacuum. It's not like we haven't seen the negative side effects of these new technologies play out already, and like Casey said, many of the people who are voicing their concerns have only gotten to live through the bad parts.
> It didn't just happen because the tool was let loose on the public and it just happened. People built the bad parts of it. They did that.
There is a JFK quote that I think accurately sums up the issue
> Victory has a hundred fathers and defeat is an orphan.
People just don't want to be associated with bad things. Billionaires don't want to be associated with the negative parts of capitalism, CEOs don't want to be associated with the terrible things their companies do, and businesses that do wrong want to settle out of court, with no public statement of blame.
I'm not sure what the solution is though. Do we say, if you don't want to take ownership over the bad things that happen then we will down play your part in the good? Do we try to set up organizations that persecute those accountable? Should Eric Schmidt be in jail? Should he be fined? Do we as developers try to use the tools "for good?" I don't know, and I'd love to know what other people have to say on this
> What does it bring to the table that isn't achievable with Cargo?
Speaking purely about the cli
dart devtool (flutter and debugging)
dart compile (More options but the big one is JavaScript transpilation)
dart info (outputs diagnostic information about installed dart toolchain)
> which isn't particularly fast
Against other programming languages that are also garbage collected Dart compares favorably, though it's implementations of things typically aims for user accessibility over maximum performance. For example a Dart Isolate is much more heavy weight than a goroutine due to it's higher startup cost and additional memory per worker. The advantage is that it has its own memory, own event loop, and communicates with other isolates only by message passing, so it's much harder to mess up.
But where Dart shines for me is in two instances. The first is as a Python programmer that wants to work in a statically typed, ahead of time compiled language. Dart fits the bill here, and covers a weakness many programming languages have which is user facing GUIs. I would argue nothing comes close to Flutter when it comes to slapping together cross platform GUIS that just work. Dart is also very good on the front and backend (with more emphasis on the frontend) of web development, and can be integrated into an existing project very well through it's ability to compile into JavaScript. Typescript definitely eats Dart's lunch here, and Go more so for the backend, but very few languages can do Webdev in a way that feels natural and due to many design decisions of the past Dart is better than most. So Dart is good for packaged user facing apps.
This also makes it a strong contender as the higher level language to pair with a lower level language. You mentioned Rust, and Dart has a Flutter Rust Bridge^1 which allows you to write normal Rust code that automatically has the glue code generated. The native code interaction story gets even better through Dart's Hooks^2, Which allow you to integrate and compile or download native assets into your Dart projects directly through Darts build interface.
> doesn't have the library ecosystem or vast training data of Rust, Go etc
LLMs are better at handling niche languages than they have ever been. And the fact that Dart is not applied broadly, in the same way Python is, means you don't need a million examples to cover the most common use cases.
Just want to throw the other Google language into the ring. While I would say Dart has a few more fancy language features than Go, it has an extremely strong and modern cli tool, which is a one stop shop for all your formatting, linking, and project building needs. It even grades how well your project is constructed before you publish it to pub.dev
When I was in grad school, my mentor once said, that he didn’t actually see programming as anything more than a tool to solve the problems he needed to solve. As someone who was excited about learning to program, I couldn’t understand it. As I’ve gotten older, I’ve come to understand him more. The language a program is written should be far down the list of reasons to use a programming language. Same with who happens to be the BFDL for the language, or what streamer is using it.
What matters more is if it does what you want it to do, and is well maintained.
I know that many garbage collected languages have ways of reducing gc pressure by minimizing classes, and pushing more things on the stack. I’ve even heard how languages like Java will allocate a massive amount of memory in the beginning, and then turn. Off the garbage collector for the whole day in high frequency trading scenarios.
Having never been in this situation, I wonder how difficult it is to bend a garbage collected language to behave like a non garbage collected one
https://www.deusinmachina.net/