I've seen Zig popup a lot recently.
What's the value proposition of Zig? It's not immediately obvious to me.
Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar?
What's the value proposition of Zig? It's not immediately obvious to me.
Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar?
But it’s not only the language itself, it is also the tooling around it. Single unit of compilation has some nice properties, allowing to support colorless async. Fast compile times. Being able to use existing C code easily and having optimization across language boundaries. Cross compilation out of the box. Generally caring for performance in all aspects.
So for me it is a better C, low-level but still approachable and not having so much cruft.
What's interesting about Zig's comptime is that while it's strictly less powerful than AST macros, it can do a lot of what macros can do while not being a metalanguage - just Zig.
A very small subset of possible lessons that could have been learned...
Nice. FWIW, I have a vague PL design in my head that does this despite being a much higher-level language. (For that matter, I think of my idea much as "like a modern Python with lessons learned".) Point being I definitely think this is a good idea.
To my understanding, the things actually called "macros" in Lisp also do this.
> Custom allocators are the norm.
On the other hand, this doesn't sound to me like an upside. Of course it's fine and well if it's easy to do this. But hopefully you'd prefer not to have to... ?
> No hidden control flow, everything is very explicit and easy to follow.
What sort of hidden control flow do you see in C? (Are modern code bases using setjmp/longjmp in new code?) I would have thought that C++ is where that really started, via exceptions. But I also don't think most programmers see that as problematic for understanding the code.
> Single unit of compilation has some nice properties, allowing to support colorless async.
Would appreciate some explanation of the theory here. Though it does occur to me that the languages I can easily think of with "coloured" async also don't exactly statically link everything all the time.
Also, how does all of this compare to Rust, in your view?
Why wouldn't you? You can often make your code simpler and more performant by using certain allocation strategy rather than relying on global allocator. Malloc/Free style strategy is also very error prone with complex hierarchical data structures where for example arena allocation can tie the whole lifetime to a single deallocation.
> Would appreciate some explanation of the theory here. Though it does occur to me that the languages I can easily think of with "coloured" async also don't exactly statically link everything all the ti
Async is moot point, it does not exist in zig right now, it used to but it was removed. There are plans to reintroduce it back, but using async as any sort of benefit for zig is not being honest.
Custom allocators are very nice. We are very much in manual memory management + optimization territory here. Having things like arena allocators makes a lot of difference in specific use-cases when you want/need every bit of performance. Also nice being able to switch the allocator for tests that is able to report leaks for example.
Yes, hidden control flow I mean something like exceptions, RAII or Rust's Dispose. So more a comparison to other languages than C.
The explanation I would refer to the talks "Don't forget to flush" or "Zig Roadmap 2026" from Andrew Kelley. Also the blog post "Zig's New Async I/O". I think it has something to do with being able to infer the required size of the stack, but already forgot the details.
https://kristoff.it/blog/zig-new-async-io/ https://youtu.be/f30PceqQWko?si=g2nLTE4ubWD14Zvn https://youtu.be/x3hOiOcbgeA?si=SUntYOYNOaxCRagc&t=3653
As to compared to Rust. The fast compile times are nice. Having a small language that you actually can understand helps to be productive. Not being restricted by the borrow checker makes it easier to implement some low-level things. Just being able to import most C code without wrapper makes the smaller ecosystem a much smaller problem. Rust is nice and certainly a good pick for many cases, but personally I often feel overwhelmed by the complexity and tons of tons of types for everything.
The tradeoff is between making sure you don't forget to write the cleanup call (Rust, C++) and making sure you don't forget to read the cleanup call (Zig). For low-level code I personally prefer Zig's tradeoff; others prefer the C++/Rust tradeoff.
I think it’s a good compromise, because the consequences of forgetting it are way harsher. Memory leaks, deadlocks…
And easier to detect. Knowing that no operation is carried out unless you can see it is important to many who do low-level programming.
But there is no one right answer. Differences between programming languages, including those between Zig and Rust, are mostly about people's personal preferences because language designers rarely make choices that are universally inferior than others. When they differ, it's because both sides are reasonable and have their proponents.
In Zig you need to call everything explicitly, meaning in the function you need to call what you want to be executed, no other code will run. The decision if you want some cleanup logic is made at the point of usage, not by the type itself.
That is the point of it, you look at a function and directly see what happens right there, not in other files/packages.
It is clear when it is called, but you have to check in code you are not currently seeing as any type could implement it. May seem like a minor thing, but is not explicit at the point of usage. In Zig only code you call explicitly runs, meaning if there is no defer nothing happens at the end of the scope.
C has macros, which is the ultimate form of hidden control flow, where a symbol can expand to any arbitrary code... also hidden allocations and functions that can error, which you could argue isn't traditionally understood as hidden control flow, but it's still nice to know when stuff is allocated and/or can create an error
Yet no string types. So lessons not so well learned. Zig does remove many warts in C.
Zig is a general-purpose programming language and toolchain for maintaining robust, optimal and reusable software.
> Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar?
Great systems language though.
Some languages aren't like this. You can't write an OS kernel in WUFFS for example and that's on purpose, that's not what WUFFS is for.
They sometimes write about how they're a general purpose language, but I strongly disagree. It's unapologetically a systems programming language; that's it's entire focus.
1. Language complexity/lack of expressivity. You want code, as much as possible, to clearly express the algorithm at the level of detail needed at the language's domain, no more and no less. The level of detail in low-level languages is different from high-level languages because, for example, you want to see exactly where and when memory is allocated/freed. Both C and C++ fail at this for opposite reasons. C is often not expressive enough to express an algorithm clearly (at least not without the use of macros), and C++ is often too implicit, hiding important details that are then easy to miss [1]. These problems may affect program correctness.
2. Lack of spatial memory safety, which is the cause of the #2 and #6 most dangerous software weaknesses (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html). Unlike spatial memory safety, Zig doesn't guarantee the lack of temporal memory safety. This would have been very nice to have, but it isn't as important and not worth compromising on the other top points.
3. Slow build times, which may also affect correctness by slowing down the test cycle.
I don't find Zig similar to C or C++ at all (certainly not as similar as Rust is to C++). If anything, Zig's risk is in being a more revolutionary step than an evolutionary one.
---
[1]: In the late eighties/early nineties (when I first learned C++), when we thought it might be a good idea for a language to be both low-level and high-level, C++'s notion of "zero-cost abstractions" seemed very interesting and even promising (I don't recall them being given that name then, but the problem - or advantage - was right there at the beginning; e.g. whether a call uses static or dynamic dispatch is an algorithmic detail that may be of interest in low-level programming, as well as whether a destructor is called, possibly through dynamic dispatch). Now that notion feels an outdated vestige of a bygone era. I'm aware there are still C++ programmers who still believe in writing high level applications in low-level languages and still believe in zero cost abstractions, but I think the industry has clearly been going the other way, and there's no indication it may be changing direction or may have any reason to do so.
I believe that in modern times, this term refers to stuff like: transparent conversion to a low-level representation (e.g. a bit-packed integer) from a high-level, statically checked datatype - e.g. a tagged union with exhaustive pattern matching, aka ADT. This is also something C++ etc lack.
Maybe Oracle could make it unavoidable on JVM, instead of keeping to use C and C++ on the runtime.
As for HotSpot, we're not going to make a bet on a language with an uncertain future, and that goes for both Zig and Rust. What is more likely to happen (and is happening already) is gradually reducing the use of low-level languages in the JVM in favour of Java itself. We've already replaced a lot of IO code in C/C++ with Java, and the implementation of reflection has already largely moved from C++ to Java.
Rust is already shipping in production for Windows, Android, Amazon and Azure infrastructure, and the Azure official language for new low level systems code, hardly questionable its adoption in the industry at scale.
Naturally someone might prove me wrong by releasing that one framework or product that makes writing Zig code unavoidable.
Really? It's heavily marketed, yet after 10+ years it's struggling to achieve even a 2% market penetration. I mean, I don't think anyone sees it as the next Fortran, C, C++, Java, Python, JS, TS, C#, Ruby, or PHP, but even Go's adoption is much higher. The numbers still look more "let's give it a shot" than "this is the future", and at its rather advanced age, that looks questionable to me. Successful technological products, even programming languages, are usually adopted much more quickly.
> Naturally someone might prove me wrong by releasing that one framework or product that makes writing Zig code unavoidable.
I have no idea if Zig will ever become successful. I mean, if Rust is struggling so badly despite the head start and hype, I don't think the chances are great. It's just that as someone who still does quite a bit of low-level programming every now and again, I find Zig a truly innovative and interesting language. I wouldn't bet on it, or on Rust for that matter, from a pure, disinterested, market numbers or historical trends point of view.
Amazon, Microsoft and Google have no reason to drop Rust and replace ongoing efforts with Zig.
Nor Apple is going to drop Swift for Zig.
Vercel tooling is powered by Rust, as yet another example. Which is quite relevant given how many SaaS products only support Next.js on their SDKs.
Anyone using a recent Volvo car is also running Rust code on some canbus units, by the way.
Those examples of Rust use by industry giants are a red flag for its adoption, because they look nothing like adoption by those very same companies of languages that ended up popular. Obviously, non-zero usage is something, but the rate and extent of adoption for what is now a fairly old language is exceptionally low compared to languages that ended up making it.
Such an unusually low adoption rate means that it will take another two decades for Rust to pick up even 50% of the low-level space (assuming some positive second derivative). It could be less if the rate suddenly picks up, but it could also be never if other competition enters the game in all that time. Nobody needs to drop Rust for competitors to have a chance because only a small minority is picking up Rust in the first place. On paper, Rust seemed to have better chances than Go in its market segment, but it's doing worse.
Rust is now at the age Java was when JDK 6 came out, and it has maybe 1-2% of the market and 5-10% of the low-level segment. That is not where Rust's believers expected or hoped it would be at this age. Could it somehow succeed in a way that's different from all successful languages before it? That's certainly a possibility, but I don't see any indication for why anyone should bet on that unusual thing happening.
I am not a C++ guy, but when Carbon is finally stable and hits the mainstream, I will definitely start trying out Carbon.
There's not much languages in that space, essentially C3 and Zig, but the former is much less advanced IMHO (also in terms of tooling).
Plus if you look at something like Zig, it syntactically starts to drift a lot as well. They left behind C's "use matches declaration" approach (thank God), capture groups look like nothing in C, function definitions are entirely different, the list goes on.
The author even states that Odin started as a Pascal clone, and was more influenced by Pascal than C.
> The language began as a Pascal clone (with begin and end and more)
> The language borrows heavily from (in order of philosophy and impact): Pascal, C, Go, Oberon-2, Newsqueak, GLSL.
I haven't tried any of these languages though, I genuinely enjoy writing dumb-as-bricks C despite all the downsides. Call it Stockholm Syndrome or whatever.
It is the route of what would have happened if Modula-2 or Object Pascal had won the industry mindshare instead of C.
I think it comes too late, we know better nowadays, so it doesn't really offer anything new.
C as a language is obsessed with the fact that C runs everywhere. Even on a DSP with a 24-bit char and a 24-bit int. If you take out those complexities and you add 40 years of lessons on language design, you can make something a lot simpler.
This makes no sense whatsoever and very far from the truth.
I don't think there is such a specific thing and certainly disagree that all idiomatic rust is somehow slower by default.
You can write rust like you might write a higher level language and then that can end up slower but if you write idiomatic low level rust, the performance is much harder to compare with C. There are things which will be faster in C and things which will be faster in Rust but broadly things will be extremely similar in performance.
I write bare metal embedded rust a lot these days and there are quite complex concepts you can represent in rust which make your code a lot safer without a performance hit.
1. Rust structs are generally smaller due to layout optimization.
2. A 10-50% difference is well within the “are you measuring debug builds?” territory.
I’m curious what code you are writing that requires unsafe all the time? I do a lot of low-level optimization, and unsafe is barely ever actually needed.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I’m not really sure what your point is by linking the benchmarks game. I mean, it’s a fun activity, but this is saying nothing about C vs. Rust. It may or may not be saying something about GCC vs. LLVM.
Why can't people just take the win of "10% slower, 10x easier"?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Also note that 3 of 4 comparisons in favor of Rust are marked "contentious" for using different algorithms with different limitations - they are not equivalents. The last one is k-nucleotide, which is a very algorithmically heavy problem where nobody has given optimized C and Rust has won at producing a decently optimized thing quickly. Note that the fastest C++ implementation handily beats Rust on that one, also.
On a similar note, I don't think it's worth talking about C as if the only C being written is highly optimized hand rolled assembly style of C. That's one in a thousand projects.
Now, as for the benchmarks game, you mean 3 of 6 comparisons in favor of Rust. Rust is winning the benchmarks against C there.
I had a look and the top Rust and C entries are using the same pcre2 library in regex-redux. Same for pidigits where both libraries are using GMP.
The only library difference I can see is that the C entries are using OpenMP and both Rust entries are using Rayon. Now, you could claim that using Rayon gives Rust an unfair advantage. But an entirely userland library beating an industry standard with support from compilers is not a good look for C.
Using Clang instead of GCC, the comparison becomes slightly better, at least for microbenchmarks that don't rely too much on libraries.
These benchmarks are still useful from a practical viewpoint - answering the question "what's the expected performance bracket of using language X in real projects today". But it doesn't say anything fundamental about the language design or even the quality of the implementation.
Also, modern online gaming with microtransactions isn't something I'd entrust to "hold my beer" languages and gaming industry development practices.
I don't think anyone should develop such games either
Memory safety bugs are very rare in modern, well-written and tested C++. The key difference is that there are no adversarial inputs, while something like a browser or server needs to deal with potentially adversarial inputs, making absolute memory safety much more important (as even a single memory safety issue could be exploited).
They're certainly not inclined to pursue safety at any expense of performance in their code.
That’s a convoluted way to say that UB is much, much worse than you think. A C program with UB is not a C program, but something else.
For me that sounds like a rather good value proposition. Too bad Zig never got the stackless corountine part they promised in the start.
There is a lot of useful technical work and ideas in it though.
I’m ranting but based the Rust/Zig discussions here on HN and the number of segfault issues in the Bun repo there is a core of truth.
Take a look at Deno and check the percentage coming from FFI with unsafe languages.
More than memory safety, I do think thread safety is a bigger challenge I'd love more modern languages to tackle.
The point is that all languages, including those two, make very clear and sometimes significant tradeoffs that may be more or less appropriate in different circumstances or for different people, and, at least so far, no consensus about the "right" tradeoff has emerged.
I am, however, very much anti claims made by some Rust fans that take an empirical and universal nature and are simply not known to be true (e.g. it is true that the more memory safety guarantees the fewer the vulnerabilities - all else being equal - but it is quite simply logically incorrect to conclude from that that the best way to minimise vulnerabilities is to have more sound safety guarantees).
I think Rust is a fantastic fit for some people who want to do low-level programming, and a pretty bad fit for others (like me). Same goes for Zig or, really, almost any language. Obviously, neither one is inherently or universally superior to the other.
BTW, my enthusiasm for Zig is not because I like all of its design decisions, but mostly because it's so different from most other languages and, in some cases, its decisions run contrary to my personal inclination (e.g. with regards to encapsulation) that I'm fascinated to know how it works out. Rust, on the other hand, is less interesting for me to think about, because aside from the more intensive typechecking (that I'm already familiar with from other languages) the overall experience it offers is quite similar to C++. Maybe I won't like what Zig ends up becoming, but for someone who's seen so many languages, it's really interesting to come across something so fresh.
Maybe you don't want to admit it at this point, but you've spent literal hours of your time (more likely tens of hours, in fact given the sheer volume of comments) on this very forum explaining why Rust was dead on arrival because it was too complex.
Now I get that such a position is hard to defend now that Rust has pretty much won and is running on everyone's phone and computer, but such a volume of disparagement on every single Rust post didn't go unnoticed.
I'm glad you've fixed your anger issue, unless you're just being an hypocrite right now.
BTW, I spend longer on sillier. Years ago, my therapist suggested spending my downtime online activity on low-stake matters, so as far as programming is concerned, you might find quite a bit of Rust and Haskell. But you should really see my Lego and whisky rants. If I were to comment much on politics or Python I would fear for my blood pressure.
There's no sore spot, though you definitely tried to find one to touch, or at least that's the only way I can rationaly explain your obsession with posting troll comments in every Rust threads for years. Which ends up getting annoying even if every single comment misses the mark.
> 10+-year-old language with less than 2% market penetration is unlikely
You seem to fail to realize that there's very little market for unmanaged languages at all. I don't think C or C++ have more than a single digit market share percentage each in 2025 either.
For most programming tasks, JavaScript and PHP are good enough and there's no way you're going to use Rust (or even Java) for those.
> I wonder what someone who reads the numbers as "Rust pretty much won" would make of, say, Go's success, that is, at best, moderate but disappointing; still well behind Ruby
Go's success is very solid compared to pretty much every language invented in the 21th century, but ultimately it fights in the same category as the mainstream giants so it's hard (read: impossible) to really become dominant.
Rust on the other hand is targeting a much narrower niche where the competition has been crippled by security vulnerabilities and poor developer experience, but also has much stricter performance characteristics, which served as a moat for a while.
For its niche, Rust has definitely won the status of “it's the future and we must use it as much as we can from now on” (though for its niche, the code tends to live much longer than for the disposable “app” code, so Rust isn't going to replace the existing C or C++ this decade or the next, and that's fine).
> BTW, I spend longer on sillier. Years ago, my therapist suggested spending my downtime online activity on low-stake matters
Weird flex but OK.
Judging from the emotion in your comment, I sense that I did touch a nerve, and I'm sorry. As a programming language/platform professional, I'm obviously interested in both language design and market adoption, and I share some of my personal perspectives. That Rust's adoption is significantly lower than that of programming languages that become dominant - in any market slice - is not something I thought is controversial, regardless of one's like or dislike of the language. But I know that some programmers make their programming language preference a part of their identity, and react emotionally to analyses or opinions they don't like.
It's normal to disagree, as experts often do, but once it gets emotional, perhaps it's best to turn away. So I apologise for causing you discomfort, and perhaps if you find my comments too distressing, just skip them and move on. Getting stressed about things like this is not worth it.
Says who? As I said above neither C or C++ aren't going anywhere in the near future, and we're talking about a programming niche where there's little new code compared to the existing base.
The fact is that most people on this planet are using an OS or a web browser that has started migrating security sensitive sections to Rust. That Rust is now part of the standard CompSci curriculum in many parts of the world. And that it's the go-to language for new low-level/performance sensitive projects.
But of course it's never going to be enough to convince the perennial naysayers.
> Judging from the emotion in your comment, I sense that I did touch a nerve
Sorry for you, but you did not manage that.
> and I'm sorry
We both know that you aren't, I know you're a troll and a flamebaiter, people like you thrive by the idea of enraging your interlocutor.
On the other side, I'm just glad I exposed your hypocrisy. Looks like pretending you were “pro-Rust” was too hard to maintain for an extended period of time.
> just skip them and move on. Getting stressed about things like this is not worth it.
Remember, you are the one with anger management issue under medical supervision, most people aren't like that ;).