I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#1].
That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause.
Zig is not memory safe, there is no way around it. It's really only as safe as C, with some helpers for making it easier to write safe code. You should really not use Zig unless you are prepared to deal with memory safety on your own. That makes it a good low-level language for system programming, but a VERY bad general purpose language. I'm writing this as a fan of Zig.
Zig only has spatial memory safety in limited situations. For example: If you use many-pointers anywhere in your codebase, those places have no spatial memory safety. If you compile in ReleaseFast, you have no spatial memory safety at all.
People say, “oh, it’s safer than C because tests can warn of missed deinits” but the fact is it isn’t memory safe by design and it’s not a priority for the language.
There are still reasons to use it and there are domains where memory safety isn’t a priority, but memory safety depends on the same mix of linters, code review, simple memory models, a deep understanding of how memory works, minimal dependencies and luck just like in C. Although none of those things will save you on their own or combined. If memory safety is a priority I’d consider other languages.
There was a discussion yesterday in which the blog author stated (and elaborated on) "I strongly disagree that Zig is safer than — even — unsafe Rust. Anyone telling you otherwise is either purposefully lying, or ignorant". That has been my experience as well. The sorts of errors I ran into were the same as in my C and HolyC experience, and not the sorts of errors I get with Rust.
More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I am unaware of solutions.
The former works via thread sanitizer, undo thread fuzzing and rr chaos mode, but I am unaware of solutions to test lock- and wait-free code besides trying really hard to create race conditions and comparing expected results to observe the race conditions, which does not cover temporal race conditions not observable at a later point.
Your statement like the general "safety" discussion is missing numbers on compilation time vs run time cost and coverage or any form of metrics to estimate risk vs benefit with cut-off values. Specifically input set/formulae coverage for functions and component planning would be interesting to discuss systems at scale (not basic code coverage), but I am unable to get decent information on that.
Looks like my definition of memory safety is wrong and it means only "Runtime makes sure incorrect memory reads/writes are not possible", not by what means, so crashing is under that definition ok.
> Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible.
Does a stack overflow trigger a crash, or does it cause undefined behavior and/or remote code execution? You'd have a point if it's the latter, but I also assumed that I would have heard about it before if that were true.
And if it's not the latter, then it's not a failure of memory safety as most people mean it.
My definition of safety is simply how many memory/UB bugs escape to production. This is quantifiable. Looking at open-source Zig projects, even highly competent programmers seem to be struggling. I’d love to dig deeper into what’s causing all these panics: how much comes from Zig’s great interop story, how much from common language footguns, and how much from its non-global-allocator-passing philosophy?
If you have the data set of known bugs, going through them should give you the cause.
I do expect a strong correlation of basic coverage for simple UB things and input set/formulae coverage for the harder to hit ones, specifically as the code scales.
For formal proofs the effort scales quadratically, does Rust code also become quadratically slower with some constant factor?
I'd assume runtime-checks could provide statistical safety and each component may need statistics tweaking unless being small enough/verified/edge cases enumerable with reasonable certainty etc.
Are you aware of any known statistics or work besides the 0,x bugs per 1000 lines of code taking into account classes of bugs?
Or what is your take on this?
I know it is not a popular view, but I really hope Zig becomes as stable in language design as C. I am tried of language design as an endless project of 'change because we can'.
I switched from objective-c to swift thinking job done, and felt like I was learning a new language with each new version. I ended up switching back to objective-c.
I think Java had a good start by defining a solid language spec (JLS) up front, which was a bible during the rapid standard library expansion days, but the JVM stayed stable at least.
I left Golang behind because of the same academic churn in language design that I saw in Swift.
So at the moment I really love coding in Zig. It already does everything I need it too already, and anyway I cant upgrade past 0.8.1 because 'old mac', and wont run on Asahi M1 because 'new mac'. But I assume in trying to be a good C replacement, these are temporary limitations, especially now it can self compile.
What I really enjoy is that I can use it for very lightweight WASM / web front-end stuff, and at the other end of the client scale, I am using it for some SOC programming on the PinePhone. I know C has the same reach, but my days of looking up ** semantics in K&R are long past!
Hopefully we'll get a solid language spec soon, and the language changes will slow to a crawl once 1.0 approaches. As for the lacking documentation that is always a complaint, I'll hopefully try to contribute to that when I start my new Zig project in May.
Anyway respect and thanks to Andrew and the team for all the hard work they are doing. It is an amazing project and I hope it works out.
If you're interested in a c-like that isn't going to change, the crwator of Odin has said the language is basically done and further work is mostly on the standard library.
FYI - it's not the official guide nor documentation.
It should be better noted on this website, but this is not the official Zig guide - which can be found here: https://ziglang.org/learn/
(And while yes, Zig does make reference to zig.guide because it's very helpful and people appreciate the effort put into it - but it's still under the other online learning resource section, not official documentation section)
So far, it feels like though there's been a bunch of things to learn, they all fit together easily in a small mental space. It does generally feel like they've redesigned C for the modern times without going overboard, and succeeded to an admirable degree in the goal of being a simple language.
It's good to have more documentation on Zig by the community, but I'm gonna throw in a bit of criticism.
One major thing I appreciate about the official Zig Language Reference is that it is no-pagination single html page that I can ctrl+f https://ziglang.org/documentation/master/ I wish more projects published their docs like that.
When I read, my mouse is busy selecting different parts of the text that I'm thinking about.
1. I don't want to move my mouse off the text to click the "next" button.
2. I don't want to move my mouse off the text to expand TOC items.
3. I don't want to waste my time on switching between pages back and forth.
I prefer the raw text on a long scrollable, non-interactive page with TOC on the side.
Otherwise, great to see more guides on the Zig topic.
Zig is great, played with it a bit to compile to WASM and found it to be pretty easy to work with.
That said, they're not winning on the docs, community and marketing front vs Rust. It's not really apples to apples, but it's a comparison people naturally draw.
For me, it's the library problem. I read the guide and think, "Wow, this is really great!" Then I read the cookbook, and it mostly says that things (like database connectivity, regex, options parsing, even HTTP GET) are not quite ready for prime time, and I should just call out to C.
Obviously, it takes time for a language to get there; I don't really mean this as a criticism. But I'm just not interested in wrapping C libraries while I wait for a zig version. I'd rather just write C. Or work in a language that is there with these kinds of things.
Since c abi powers the world, with zig’s ability to easily wrap c libs, not only does zig have access to all libs; it also makes it easy to integrate zig with any existing project as most programming languages have integration with c.
This is why everybody says just use some existing c lib
Hmm. I could substitute lots of languages for zig in that first sentence. But that doesn't invariably lead the communities that maintain those languages to utter the second.
I also doubt I have space to enumerate the languages that claim to "easily wrap c libs." None of them easily do that. That statement imagines that there's some basic consistency between APIs (and that those APIs are asking for and returning fairly simple types).
The thing is, all valid C types are also valid in Zig. You just `@cImport` the header file and use it. You don't need to wrap the API, you just use it.
In C, C imports are in the global namespace. The language is also compiled sequentially, so often, time is spent ensuring headers are included in the proper order, hopefully avoiding a cyclic dependency. In Zig, C imports are done in a struct with a local namespace or imported package definition and the ordering is not relevant to compilation.
I think parent means that Zig is a better language with regards to being the target for C to be imported into than C and that is the benefit of being a more modern language with flexibility following more modern conventions. This is combined with the mostly seamless ability to utilize most C functions and types without too much strife.
problem is that the language started hitting its stride and getting attention while the core team is on a 2 year side quest of rewriting the compiler + incremental compilation
I first heard about zig this May and since then I hear more and more often about it. I wonder if it’s baader-meinhof or is Zig actually gaining popularity?
Both things can be true. This most recent hype cycle seems to be riding the wave from the related hype of Ghostty's public release and Bun's latest release. And recently, another project with decent name recognition by some announced intentions to rewrite in Zig. Other than the latter event which is merely an announcement as of now, this language is showing up in projects that people are paying attention to. That only brings more attention and to a degree, a certain amount of credibility, especially when the lead developer for Ghostty has a well-earned and positive reputation among the engineering community.
To me, it seemed more like Rust and Zig started gaining popularity around the same time, a few years ago. Then people realized that Zig was in a much earlier state of development than they'd assumed, and had barely any resources to get into it, so the mindshare went mostly towards Rust alone. This is Zig is hitting a second wave.
As someone that was around when C started to be adopted in home computers, followed by C++ adoption several years later, and remembers C vs C++ flamewars on USENET, the popularity comparison made me smile.
From my perspective rust is still getting a lot (most) of the attention while zig has a loyal but smaller following. Odin (one I love) has an even smaller following still.
Personally, I don't really care about languages. I'll use whatever language I have to in order to try a library/engine I'm interested in. Currently I'm looking at trying Godot, Bevy and O3DE. As they all seem to be used to some extent right now. Note that none of those are written in Zig (or Odin). Maybe that will change after 1.0?
That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause.
[#1]: https://github.com/ziglang/zig/issues/2646
[#2]: https://github.com/oven-sh/bun/issues?q=is%3Aissue+segfault
People say, “oh, it’s safer than C because tests can warn of missed deinits” but the fact is it isn’t memory safe by design and it’s not a priority for the language.
There are still reasons to use it and there are domains where memory safety isn’t a priority, but memory safety depends on the same mix of linters, code review, simple memory models, a deep understanding of how memory works, minimal dependencies and luck just like in C. Although none of those things will save you on their own or combined. If memory safety is a priority I’d consider other languages.
More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I am unaware of solutions. The former works via thread sanitizer, undo thread fuzzing and rr chaos mode, but I am unaware of solutions to test lock- and wait-free code besides trying really hard to create race conditions and comparing expected results to observe the race conditions, which does not cover temporal race conditions not observable at a later point.
Your statement like the general "safety" discussion is missing numbers on compilation time vs run time cost and coverage or any form of metrics to estimate risk vs benefit with cut-off values. Specifically input set/formulae coverage for functions and component planning would be interesting to discuss systems at scale (not basic code coverage), but I am unable to get decent information on that.
Does a stack overflow trigger a crash, or does it cause undefined behavior and/or remote code execution? You'd have a point if it's the latter, but I also assumed that I would have heard about it before if that were true.
And if it's not the latter, then it's not a failure of memory safety as most people mean it.
For formal proofs the effort scales quadratically, does Rust code also become quadratically slower with some constant factor? I'd assume runtime-checks could provide statistical safety and each component may need statistics tweaking unless being small enough/verified/edge cases enumerable with reasonable certainty etc. Are you aware of any known statistics or work besides the 0,x bugs per 1000 lines of code taking into account classes of bugs? Or what is your take on this?
Much better than C will ever be, but still with gotchas like use after free, or hardware mapped variables.
https://github.com/ityonemo/clr
I switched from objective-c to swift thinking job done, and felt like I was learning a new language with each new version. I ended up switching back to objective-c.
I think Java had a good start by defining a solid language spec (JLS) up front, which was a bible during the rapid standard library expansion days, but the JVM stayed stable at least.
I left Golang behind because of the same academic churn in language design that I saw in Swift.
So at the moment I really love coding in Zig. It already does everything I need it too already, and anyway I cant upgrade past 0.8.1 because 'old mac', and wont run on Asahi M1 because 'new mac'. But I assume in trying to be a good C replacement, these are temporary limitations, especially now it can self compile.
What I really enjoy is that I can use it for very lightweight WASM / web front-end stuff, and at the other end of the client scale, I am using it for some SOC programming on the PinePhone. I know C has the same reach, but my days of looking up ** semantics in K&R are long past!
Hopefully we'll get a solid language spec soon, and the language changes will slow to a crawl once 1.0 approaches. As for the lacking documentation that is always a complaint, I'll hopefully try to contribute to that when I start my new Zig project in May.
Anyway respect and thanks to Andrew and the team for all the hard work they are doing. It is an amazing project and I hope it works out.
What? Go is one of the most stable languages I can think of. What churn are you referring to?
It should be better noted on this website, but this is not the official Zig guide - which can be found here: https://ziglang.org/learn/
(And while yes, Zig does make reference to zig.guide because it's very helpful and people appreciate the effort put into it - but it's still under the other online learning resource section, not official documentation section)
So far, it feels like though there's been a bunch of things to learn, they all fit together easily in a small mental space. It does generally feel like they've redesigned C for the modern times without going overboard, and succeeded to an admirable degree in the goal of being a simple language.
One major thing I appreciate about the official Zig Language Reference is that it is no-pagination single html page that I can ctrl+f https://ziglang.org/documentation/master/ I wish more projects published their docs like that.
When I read, my mouse is busy selecting different parts of the text that I'm thinking about.
1. I don't want to move my mouse off the text to click the "next" button.
2. I don't want to move my mouse off the text to expand TOC items.
3. I don't want to waste my time on switching between pages back and forth.
I prefer the raw text on a long scrollable, non-interactive page with TOC on the side.
Otherwise, great to see more guides on the Zig topic.
That said, they're not winning on the docs, community and marketing front vs Rust. It's not really apples to apples, but it's a comparison people naturally draw.
Obviously, it takes time for a language to get there; I don't really mean this as a criticism. But I'm just not interested in wrapping C libraries while I wait for a zig version. I'd rather just write C. Or work in a language that is there with these kinds of things.
This is why everybody says just use some existing c lib
I also doubt I have space to enumerate the languages that claim to "easily wrap c libs." None of them easily do that. That statement imagines that there's some basic consistency between APIs (and that those APIs are asking for and returning fairly simple types).
(If you're hearing a combative tone, it's unintended; I'm asking seriously, because I would love for this to be true!)
I think parent means that Zig is a better language with regards to being the target for C to be imported into than C and that is the benefit of being a more modern language with flexibility following more modern conventions. This is combined with the mostly seamless ability to utilize most C functions and types without too much strife.
The unstable part might be why. That said, I’m a little familiar with it as it’s what Bun uses.
I see zig catching up in popularity because people are appreciating the simplicity it is trying to achieve.
Personally, I don't really care about languages. I'll use whatever language I have to in order to try a library/engine I'm interested in. Currently I'm looking at trying Godot, Bevy and O3DE. As they all seem to be used to some extent right now. Note that none of those are written in Zig (or Odin). Maybe that will change after 1.0?