> Writing memory safe code in unsafe languages requires global reasoning
If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty much never.
If your code is a RAII and abstraction maze, then yes, you will probably need global reasoning, but that's not the case with Zig.
Arena allocators are great for certain use cases, but they don't provide any solutions to memory unsafety; they don't do anything for use-after-free, they don't do anything for buffer overruns, they don't address any sources of undefined behavior, and they don't do anything for thread-safety, which is a requirement for memory safety.
I think you will be surprised by how many developers do not have this same list of priorities (or in that order) when developing software.
I posted this link at the same time when I posted it to Lobsters (https://lobste.rs/s/g6lkw1/my_software_north_star) 3 days ago, but it didn't get on the front page. Seeing that the submission time has been reset, I imagine it was given a second chance by HN curators (it's a known process), but that doesn't mean free upvotes, it's just that some people resonate with the thinking.
The truth is a bit of everything, bun being a messy codebase written primarily with "move fast and break things" in mind, cultural divergence between Bun and the Zig community, and also hiring issues. People maybe forgot but Jarred at some point caused a bunch of drama when he tweeted that working at Bun is not for people that value life/work balance, which went viral and caused an uproar. Must not have been super easy to hire from the Zig community after that, and in fact once Bun got acquired by Anthropic, it was pretty much Jarred and Claude doing all the work on the codebase. Pivoting to Rust is probably at least in part a way to reset the clock on those hiring interactions.
> I imagine it's a difficult time to be a Zig developer.
In some ways it always has been, the community was 'born' in the middle of the pandemic, then for a long time there was a constant influx of Rust zealots coming into threads about Zig to remark how immoral it is to use Zig, and now LLM shovel sellers are telling everybody that the only way forward is to become efficient at consuming tokens.
But it's actually not that bad.
The Zig community is growing pretty well, useful software is being written in Zig, and the advantages that Zig brings are still valid whether you hand-code or use LLMs (e.g. cross-compilation of C/C++ code).
That is correct, this blog post is about understanding the priority of various subgoals and the ultimate goal (creating useful software). Memory-safety is important but overfitting on that subgoal, as I believe the memory-safety blog post is doing, won't make you create better software.
If Rust helps you get all the way to correctness, then great, but that blog post was insane.
> For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself.
The solution, IMO, is a strictly worse version than what we chose in the Zig project (banning LLM contributions).
> AI tools have changed the economics of this very quickly. We use them ourselves every day, but a pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.
Things that worry me about this choice:
- open source is a tough business and you need to leverage the good things about it to make it worth doing. contributors bring in a huge amount of value that they offer you essentially for free (see contributor poker: https://kristoff.it/blog/contributor-poker-and-ai/), on top of being a hugely valuable recruitment funnel. They're rejecting all of that, which seems insane to me.
- one could argue that LLMs could fill that gap but, first of all they could have just banned LLM usage only in PRs from untrusted contributors, and second even the best LLM:
1. is a cost, not just free value, and the price of tokens is increasing
2. the code has to be reviewed anyway, unless you think that just passing tests is good enough for a browser
3. ultimately can't become a trusted core contributor able of taking ownership of a part of the codebase
- removing the influx of code that comes from PRs means that over time the whole project will have a small number of contributors that own all the code, making it easier for the project to do a license rugpull. when copyright ownership is well distributed this kind of thing is harder to pull off.
Overall, this is not good in my opinion. They're making open source a more problematic business model for them than it has to be, while at the same time making it harder to recruit more core contributors, as the code ownership coalesces to small group of people.
This is an obvious recipe for disaster (a rugpull), and I'm forced to wonder if this is just by mistake or if some of the Ladybird sponsors are playing a mean game of Secret Hitler. I guess only time will tell.
The Zig project is making a real difference in the culture of open source software. I'm so glad for the leadership and community. It's a refuge from the mania of large language models disrupting this and other industries, steamrolling over human connection, decency, ingenuity, class, taste. These intangible qualities that make it worthwhile, joyous and fun, will be destroyed unless people put in effort to protect them.
Comments in this thread that insist open source has nothing to do with community, that it's simply a licensing matter, is disappointing and shows a lack of understanding of what's it's all about. Similarly with the community of mathematicians. Some people reduce it to "Math is just a tool", which is just ignorant and sadly misses the beauty, wisdom, camaraderie, and the humanity of the endeavor which is what matters.
>This is an obvious recipe for disaster (a rugpull), and I'm forced to wonder if this is just by mistake or if some of the Ladybird sponsors are playing a mean game of Secret Hitler. I guess only time will tell.
When I first read this I checked the license and saw that a rugpull would be permitted. However, if someone wants to continue the project after the rugpull they could do something thing like the redis rename to redict.[0]
DVUI is I think the most mature zig gui project, and a very good immediate-mode approach imo.
Here's a recently released open source project built on DVUI in zig: https://fizzyed.it/
If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty much never.
If your code is a RAII and abstraction maze, then yes, you will probably need global reasoning, but that's not the case with Zig.
reply