As a developer interested in zig it is nice to see books being release, but I'd be a bit resitant to buy anything before zig reaches 1.0 or at least when they settle on a stable api. Both the builder and the std keep changing. Just 0.15 is a huge breakage. Does anyone knows how those changes would affect this book?
People are doing real companies with Zig (e.g. Tiger Beetle) and important projects (e.g. Ghostty) without the 1.0 backward compatibility guarantee. Zig must be doing something right. Maybe this also keeps opinionated 9-5er, enterprise type devs out of it as well which might be a good thing :).
As a Zig adopter I was rooting for this because even though there is the official documentation and some great community content, it's nice to just kick back and read a well written book. I'm also very happy with other Manning titles; they have built a high level of trust with me.
To answer your question is it too early. My expectation is that the core language, being quite small by design, will not change that much before 1.0. Some things will, especially async support.
What I think we will see is something like a comprehensive book on C++14 . The language is not much changed between now and then, but there will be new sections to add and some sections to rework with changes to the interface. The book would still be useful today.
Not a perfect analogy because C++ maintains backwards compatibility but I think it is close.
Not a comment on the book but I hope a slightly off topic thread is OK...
As a systems programmer, what is the selling point of Zig? For me, memory safety is the number 1, 2, 3, 4 and 5 problem with C. A new language that doesn't solve those problems seems very strange to me. And as a counterpoint, I will tolerate massive number of issues with Rust because it gives us memory safety.
I work in security so that may give me a bias. But maybe instead of "bias" it's more like awareness. If you don't deal with it day in, day out, it seems impossible to really internalise how completely fucking broken something like the Linux kernel is. Continuing to write e.g. driver code in an unsafe language is just not acceptable for our civilisation.
But, also maybe you don't need full complete memory safety, if a language has well designed abstractions maybe it can just be "safe enough in practice". I've worked on C++ code that feels that way. Is this the deal with Zig?
Excellent way to stay busy producing revised editions over the next few years.
I really enjoy writing Zig and I think it's going to be an important language in the future. I do not enjoy porting my code between versions of the language. But early adopters are important for exploring the problem space, and I would have loved to find a canonical source (aside from the docs, which are mostly nice) for learning the language when I did. A text that evolves with the language has a better chance of becoming that canonical onboarding source.
I think this is great, gives those wanting a good formal foundation a guide to getting organized and making something happen.
With time this is also going to be great for the author with new iterations of the book, but getting in early like this can set the author and the language up for success long term.
Zig certainly has a lot of interesting features and good ideas, but I honestly don't see the point of starting a major project with it. With alternatives like Rust and Swift, memory safety is simply table stakes these days.
Yes, I know Zig does a lot of things to help the programmer avoid mistakes. But the last time I looked, it was still possible to make mistakes.
The only time I would pick something like C, C++, or Rust is if I am planning to build a multi-million line, performance sensitive project. In which case, I want total memory safety. For most "good enough" use cases, garbage collectors work fine and I wouldn't bother with a system's programming language at all.
That leaves me a little bit confused about the value proposition of Zig. I suppose it's a "better C". But like I said, for serious industry projects starting in 2025, memory safety is just tablestakes these days.
This isn't meant to be a criticism of Zig or all of the hard work put into the language. I'm all for interesting projects. And certainly there are a lot of interesting ideas in Zig. I'm just not going to use them until they're present in a memory safe language.
I am actually a bit surprised by the popularity of Zig on this website, given the strong dislike towards Go. From my perspective, both languages are very similar, from the perspective that they decided to "unsolve already solved problems". Meaning, we know how to guarantee memory safety. Multiple programming languages have implemented this in a variety of ways. Why would I use a new language that takes a problem a language like Rust, Java, or Swift already solved for me, and takes away features (memory safety) that I already have?
> I am actually a bit surprised by the popularity of Zig on this website, given the strong dislike towards Go.
I'm not sure that's true, that there is a strong dislike towards Go on here. Maybe that's just competitors or their zealots creating such a perception. Even if that was the case (it being disliked on here), it would only hold true for this site, and not in general. Go is ranked as a top 10 language by TIOBE (as of October 2025). Rust is ranked 16, Swift is ranked 22, Vlang is ranked 42, and Zig behind it at 43.
> for serious industry projects starting in 2025...
In regards to starting projects with Zig, as long as people are clear that it's still in beta, then they should be fine with accepting the risks that go along with that. It's also fine not to want to use Zig and stick with the language that you are comfortable with. If a person wants to experiment or to see what's available, there are many languages in the "better C" or "C alternative" category.
13 comments
[ 0.18 ms ] story [ 32.5 ms ] threadTo answer your question is it too early. My expectation is that the core language, being quite small by design, will not change that much before 1.0. Some things will, especially async support.
What I think we will see is something like a comprehensive book on C++14 . The language is not much changed between now and then, but there will be new sections to add and some sections to rework with changes to the interface. The book would still be useful today.
Not a perfect analogy because C++ maintains backwards compatibility but I think it is close.
Just to gauge interest?
As a systems programmer, what is the selling point of Zig? For me, memory safety is the number 1, 2, 3, 4 and 5 problem with C. A new language that doesn't solve those problems seems very strange to me. And as a counterpoint, I will tolerate massive number of issues with Rust because it gives us memory safety.
I work in security so that may give me a bias. But maybe instead of "bias" it's more like awareness. If you don't deal with it day in, day out, it seems impossible to really internalise how completely fucking broken something like the Linux kernel is. Continuing to write e.g. driver code in an unsafe language is just not acceptable for our civilisation.
But, also maybe you don't need full complete memory safety, if a language has well designed abstractions maybe it can just be "safe enough in practice". I've worked on C++ code that feels that way. Is this the deal with Zig?
I really enjoy writing Zig and I think it's going to be an important language in the future. I do not enjoy porting my code between versions of the language. But early adopters are important for exploring the problem space, and I would have loved to find a canonical source (aside from the docs, which are mostly nice) for learning the language when I did. A text that evolves with the language has a better chance of becoming that canonical onboarding source.
With time this is also going to be great for the author with new iterations of the book, but getting in early like this can set the author and the language up for success long term.
Yes, I know Zig does a lot of things to help the programmer avoid mistakes. But the last time I looked, it was still possible to make mistakes.
The only time I would pick something like C, C++, or Rust is if I am planning to build a multi-million line, performance sensitive project. In which case, I want total memory safety. For most "good enough" use cases, garbage collectors work fine and I wouldn't bother with a system's programming language at all.
That leaves me a little bit confused about the value proposition of Zig. I suppose it's a "better C". But like I said, for serious industry projects starting in 2025, memory safety is just tablestakes these days.
This isn't meant to be a criticism of Zig or all of the hard work put into the language. I'm all for interesting projects. And certainly there are a lot of interesting ideas in Zig. I'm just not going to use them until they're present in a memory safe language.
I am actually a bit surprised by the popularity of Zig on this website, given the strong dislike towards Go. From my perspective, both languages are very similar, from the perspective that they decided to "unsolve already solved problems". Meaning, we know how to guarantee memory safety. Multiple programming languages have implemented this in a variety of ways. Why would I use a new language that takes a problem a language like Rust, Java, or Swift already solved for me, and takes away features (memory safety) that I already have?
I'm not sure that's true, that there is a strong dislike towards Go on here. Maybe that's just competitors or their zealots creating such a perception. Even if that was the case (it being disliked on here), it would only hold true for this site, and not in general. Go is ranked as a top 10 language by TIOBE (as of October 2025). Rust is ranked 16, Swift is ranked 22, Vlang is ranked 42, and Zig behind it at 43.
> for serious industry projects starting in 2025...
In regards to starting projects with Zig, as long as people are clear that it's still in beta, then they should be fine with accepting the risks that go along with that. It's also fine not to want to use Zig and stick with the language that you are comfortable with. If a person wants to experiment or to see what's available, there are many languages in the "better C" or "C alternative" category.
The language isn’t even stable, which is pretty much the opposite of something you can rely on.
We’ll know in many years if it was something worth relying on.