I’ve been looking into Zig for a couple of days now, digging deeper and deeper in search of conceptual flaws and weaknesses in its design, and I’ve found… zero!
Replacing C isn’t easy—not so much because of the vast amount of existing code and libraries, but because, in low-level and systems programming, C is absolutely lethal. So, finding a modern replacement for it is a real challenge.
There are three possible candidates: D, Rust, and Zig.
In my opinion, D would be the top choice among these three: as powerful as C++ but without its absurdities and inefficiencies. However, mistakes in its management have relegated it to a negligible niche—so small it might as well not exist.
Rust: what can I say about Rust other than it’s full of fantastic ideas? Ideas that I’ve borrowed heavily from while writing a C library to give me the same ownership model for heap objects. But there’s a problem: if you’re “born” into Rust, everything is simple and intuitive. But if you try to learn Rust after forty years of other programming philosophies… good luck! You’ll never truly master it. Or maybe I’m just an idiot—that’s entirely possible.
And then there’s Zig: does this language really exist, or is it a dream? Because here, everything seems perfect. No matter how hard I’ve tried, I haven’t been able to find a single flaw in its design.
So, there are three possibilities: either this is all a dream, and tomorrow morning Zig will no longer exist; or there’s some hidden catch I haven’t spotted yet; or, just maybe, we finally have the true successor to C.
Rust i just fundamentally dont agree with some of the decisions made in the language design. Also i like to model my programs in a specific way, thinking of the memory my program occupies and work / optimize a lot based on that. That is something Rust is really hostile to.
Zig is great, i agree almost with every decision made by the Zig S. F., altho i have to say there are still some sharper edges:
The language is a bit immature and documentation is often outdated (i can work with that tho)
LSP even tho got a lot better in past 3 years, still has problems with code using a lot of comptime (there is proposal to fix it in the future, will be a lot of work tho)
Math and casting logic is really verbose, again there are proposals and ideas to make it better while not losing the explicitness it gives you (which is awsome).
Overall the language is really verbose, i dont mind it, but many might dislike it.
Current ecosystem is still not there, yes you can wrap around almost any C library with no to little effort, but still its not as “ergonomic” as Zig libraries.
There are still some “unsolved” potentially breaking chnages, you can find them on the github, just to be aware of them.
Overall the language has bright future and i already use it for all my personal projects, but there is still a bit of a road ahead.
@Bobvan Trust me, Bob—D is a damn fine language, and it brings one killer feature to the table: scalability.
You can use it practically like C, then sprinkle in extra power and flexibility only where you need it. This hybrid approach works beautifully, leading to elegant, efficient code that only uses the language’s best features (the subjectively best ones, obviously).
So if it’s so well-designed, why does only a dozen programmers worldwide use it? Simple: the language isn’t the problem—the management and community are.
Let’s not kid ourselves: if you wanna replace a heavyweight like C, everything has to be top-tier—including governance.
Rust? Look, if I were 20 instead of 60+, I’d jump into Rust without a second thought. For those born into Rust, what we call ‘difficulties’ just become part of their coding philosophy.
Zig? Nothing’s perfect, Bob—but starting with a coherent, well-designed foundation is what matters. And that’s how I see Zig today: it started strong. Really strong.
The main problem I have with D (in context of the sokol-header D bindings) is tooling. I haven’t had a single time were I could simply build a D project after a long while, one thing or another is always broken on ARM Macs. Only the state of Android build tools is worse IMHO.
Last time C compiler tooling was so broken was before cmake in the 1990s when all we had was GNU make and autotools (yuck).
As much as cmake might suck as a scripting language, at least I never had any problems building cmake-based projects, no matter if on Linux, macOS or Windows.
I’m not a fan of Rust the language, but they got the build tooling right with cargo.
Same with zig build run (and the language ergonomics are much better than Rust).
Also - IMHO where D gets really confusing is its automatic memory management, in a way it’s more complicated to deal with memory in D than even C, at least C is predictable, while in D we ran into problems that sometimes a struct that’s supposed to be passed by value into a C library function simply ‘disappears’ before the C function is called - etc etc etc… it is a highly confusing language for newcomers IMHO.
Did they though? It’s nice and simple, sure. But it also frequently downloads the Internet, and encourages depending on an enormous amount of tiny packages. Slow, and not great in terms of managing supply chain attacks. This is partially cultural, but enabled by the tooling. I pray Zig doesn’t end up there.
IMO Zig and Rust target a bit different audience.
The “average” web dev would not have great time with Zig, and that is not meant as an insult, i just dont think the language is well suited for build fast and break fast culture web dev is used to.
On the other hand Rust is not perfect for it either, but the age of ecosystem makes it easier i suppose.
@floooh
As I was saying, unlike Rust (for example) D is scalable, it does not impose the use of its features but you can freely choose what to use and what not, everyone can develop their own D coding style.
You don’t like memory management via the garbage collector? I don’t either, so I call free explicitly.
Kinda high level at some areas (i come form C background and am overall really sceptical of over-abstracting)
It smelled of C++ too much for my liking
The “use only the features you like” is really common in C++ where you have most of the features you want and ALL the features you dont. Which really hurts when cooperating / integrating with foreign code with different “set of features”
To be fair i didnt give D a really long time, mabye my view would shift after years of using it. But that is my current opinion
@Bobvan
To me Zig seems more than suitable for general use, even in projects of considerable complexity.
I think it will prove to be a valid substitute for C in my usual combination of C# for the framework and C for the highly efficient code.
So I really think that LSSA will be written C# + Zig (maybe + Python).
Why do you see it suitable for the web?
@andrewrk
If I may, Andrew, a key factor for Zig’s widespread success—which I must commend you for once again—is robust support for professional Windows tooling. This typically means Visual Studio Pro and JetBrains suite.
Many enjoy working with Linux, but in enterprise environments, Windows is the standard, and development relies on professional-grade tools—not forks of VS Code.
Most critically, AI integration is now indispensable. Visual Studio is beginning to struggle due to its poor AI support, a weakness JetBrains is aggressively exploiting.
Like it or not, the current industry standards are clear: Windows + VS Pro/Enterprise or JetBrains.
The only thing that really matters for system programming (more than syntax, package mgt, lsp tooling, etc etc) is … the compiler output
Smaller, faster, better, most correct
If compiler X produces better binaries than compiler Y, then X wins every time.
If compiler X takes 3 times the effort to get it right, that’s almost irrelevant.
Zig in its current form is a decent compromise. It’s producing really good binaries, and the language side of it makes it relatively easy to see what the hell it’s doing in there.
Bonus points - it’s quick and relatively easy to use, with no horrid abstractions
Double bonus points - it’s not some captive technology controlled by people I don’t like
So until something much better pops up (or if zsf goes off the rails and becomes the embodiment of pure evil) … it’s my preferred language for all the things
@zigster I would agree if you’d called Zig ‘the perfect language’—which clearly cannot exist, because language design inevitably clashes with the constraints of real-world hardware implementation.
More modestly, I’ve defined Zig as the only credible successor to C for those approaching it with experience in other development paradigms. And believe me, that alone is an enormous achievement.
Now, could Zig still derail?
Absolutely. For example:
If companies don’t adopt it, it’s guaranteed to veer off into irrelevance.
It could also derail due to internal missteps in implementation choices (though this is now unlikely, since its core architecture is already sound).
The third risk is lack of standardization or overly frequent releases—both of which directly threaten enterprise adoption.
So yes, there are plenty of potential pitfalls. But the only one that truly matters is the first: Will the corporate world embrace it?
Let’s be blunt: Large-scale enterprise adoption is the ultimate determinant of a programming language’s success or failure.
I’ve put D to pretty extensive use. For me, it’s very close to the ideal language. I love having really strong comptime and code generation features available to me within the language, in a single step of tooling, rather than often having to do codegen as a separate step as in most other languages. (Including Zig!) But it certainly comes with some drawbacks. I’ve come to the opinion that D’s inability to break through to wider success comes from three root problems:
Support for visual debuggers is weak. There is apparently a workflow to get it working with Visual Studio, but it’s not very well documented, and hardly anyone actually wants to work with VS. I think it’s possible the state of things may be a little better with more recent tools like RemedyBG, but good luck finding easy steps to follow to get that working.
It has poor portability. DMD, the reference compiler, only has an x86 backend, and support for other platforms by LDC (which has an LLVM backend) are frustrated by D’s runtime being relatively heavy. There seems to be some work in making this better in recent years with the -betterC compiler switch, which cuts out most of the runtime, but the last time I tried using this I ended up running into weird and cryptic compiler bugs. In general, D occupies this odd middle ground in between low-level and high-level. It feels extremely ergonomic as a more modernized C/C++ … right up until the point where the heavy runtime and the standard library’s reliance on garbage collection start to get in the way, at which point it begins to feel like a worse .NET.
The standard library, Phobos, relies heavily on templates, and especially on recursive templates. This is generally presented as the idiomatic way to work with D’s comptime features. But I’ve heard from someone who has both used and contributed to DMD professionally that the performance cost adds up quickly in larger projects. And though this performance problem can generally be solved by leaning more on code generation by using CTFE to build strings to use in mixins, this is harder to write, harder to read, harder to debug, and nowhere near as well favored and supported.
(An honorable mention 4. would be the relatively sparse package ecosystem, though I think that’s more of a symptom and less of a root cause in itself.)
Nah, tbh, that’s just your bubble I’ve been coming from such a 100% Windows bubble too (PC game development), but once you look outside, this is just one niche among many. Probably over 90% of software development happens for the web, and there the development platform doesn’t matter anymore (e.g. the company I work for nowawadays develops web games, and we have a wild mix of Linux, macOS and Windows laptops, basically whatever a specific developer prefers, and such a mixed setup is also more resistant to ‘works on my machine’ problems).
In general, it’s up to the IDE developers to add Zig support if they don’t allow an extension system like VSCode, the Zig language ecosystem should mainly focus on making such extensions easy to build (by providing a language server and standard debug info).
Basically - I think we’ll see much more diversity in the near future when it comes to development platforms, just because young programmers don’t necessarily start on Windows anymore, but on cheap hand-me-down laptops with a Linux distro slapped on.
(but yeah, that’s probably not ‘averag web dev’).
I’ve been coming from such a 100% Windows bubble too (PC game development), but once you look outside, this is just one niche among many. Probably over 90% of software development happens for the web, and there the development platform doesn’t matter anymore (e.g. the company I work for nowawadays develops web games, and we have a wild mix of Linux, macOS and Windows laptops, basically whatever a specific developer prefers, and such a mixed setup is also more resistant to ‘works on my machine’ problems).