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?
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?
Like a modern C with lessons learned. Instead of macros it uses Zig itself to execute code at runtime (comptime). Custom allocators are the norm. No hidden control flow, everything is very explicit and easy to follow.
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.
> Instead of macros it uses Zig itself to execute code at runtime (comptime).
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?
Comptime is very nice but certainly more limited then Lisp. You can't generate arbitrary code with it. But good enough to implement something like JSON serialization or Struct-of-Arrays in normal code that is readable.
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.
> Yes, hidden control flow I mean something like exceptions, RAII or Rust's Dispose. So more a comparison to other languages than C.
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
Rust dispose? I think you mean drop. But I don't see how that is hidden control flow. It's very clear when it drop is called.
It's clear once you know that an object implements the Drop trait, but you can't see that at the use site, ergo it's hidden (same goes for C++ destructors). Zig wants every call to be visible.
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.
A funny thing I’ve noticed is that some Rust programmers will explicitly call `std::mem::drop(…)` in tricky situations where it really matters, like releasing a mutex with complex interactions - even at the end of scope. I kind of like it whenever a lock is held for more than a few lines.
I think it’s a good compromise, because the consequences of forgetting it are way harsher. Memory leaks, deadlocks…
> I think it’s a good compromise, because the consequences of forgetting it are way harsher.
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.
What do you mean if an object implements a drop? Whether an object implements a drop has no bearing on when it is called. I mean a developer can manually call it. But it is always clear when it is called.
The point is the code is on another type. Any variable could by of a type that implements some Drop logic. It is mostly called implicitly where it is used, wether you as a programmer are aware of it or not. You would need to check.
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.
People seem to underestimate this. One of the first reasons I noticed about c++ was trying to figure out what functions were being called in an overly complex inheritance hierarchy. The next was from hidden behavior from seemingly benign looking sequence of statements. Both of these are a barrier of entry for bringing in new coders to a complex code base.
Drop yes. Thanks for the correction.
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.
> 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... ?
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.
Regarding async I kind of agree with you right now, but the new design is there and currently getting implemented. If you don’t believe it will work out or need to use async right now sure, use something else. It is not a stable language yet and very much WIP. I don’t think it’s dishonest to write about something that has a design and is worked on right now with a realistic chance of working out.
Sure and I'm excited for it (especially stackless), but I'd be wary of marketing something that doesn't actually exist yet.
> Like a modern C with lessons learned.
Yet no string types. So lessons not so well learned. Zig does remove many warts in C.
It has proper arrays and slices, even being able to define a sentinel value in the type system, so you know when it is a C string or a slice with a specific size with arbitrary values. Strings can become a problem if you need another encoding than the chosen one. Then you start to use byte slices anyway. You need to allocate a new one if you want to change just a part of it. Safer yes, but can produce unwanted overhead and you have to duplicate many APIs for strings and byte arrays as it is the case in Go.
It feels like C but raised with Java as its strict stepfather.
Many of those warts were already not present in other systems languages predating C, and others of similar age.
To be clear, the problem with C isn't macros, but text based macros. Syntax based macros are really good (as shown by Lisp and friends)
AST macros are very powerful. As to them being "good", that's debatable. They have advantages but also disadvantages. For one, they operate on syntax, so they're a separate metalanguage and not so pleasant to debug. For another, they are referentially opaque (i.e. when passed different expressions with the same meaning, they can produce different results), which makes them powerful but also mysterious.
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.
To be clear, we all know GP is talking about C macros.
Not only being text based but also having another separate language is problematic. Rust also has powerful declarative macros but it is it’s own language. Procedural macros and crabtime are imho a bit better for more complex cases as you write Rust.
I’m not sold that they’ve actually solved the coloring problem vs given it a different syntax.
> with lessons learned
A very small subset of possible lessons that could have been learned...
I've seen the custom allocators mentioned many times as central to the value proposition. Do the allocators shipped with the standard library compose the system allocator, or are they completely distinct from the *alloc family shipped as part of libc?
You can ofc use the *alloc from libc if you want. Otherwise there are different ones in the standard library, ArenaAllocator wraps another allocator, FixedBufferAllocator uses a given byte slice. I recommend to take a look at https://ziglang.org/documentation/master/std/#std.heap to get an overview.
The value proposition of Zig is it's the most ergonomic way to do systems programming I've ever seen. First class allocators, arbitrary width integer types, top notch bindings to OS syscalls in the std lib without relying on libc, and you can translate C bindings to Zig at compile time, so no FFI layers for existing libraries.
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.
Maybe read https://ziglang.org/ ? They list the goals:
and how they are trying to achieve that: simple language, and 'comptime' for metaprogramming (a more or less new approach). No, not really.I don't think it's a general-purpose programming language at all.
Great systems language though.
Looks general purpose to me. What purposes couldn't you use Zig for? A general-purpose programming language isn't necessarily good for every purpose but it can be used. For example both Java and C are general purpose languages. Should you write an OS kernel in Java? Maybe that's unwise but people did. Should you write a web browser in C? Again unwise but people did.
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.
Zig’s undefined behavior story is not nearly as much of a minefield for one. That should be enough really. If you think the CPP is good enough for metaprogramming, I don’t know what to tell you either.
It's a language that attempts to solve more of the biggest issues with low level programming than any other current low-level programming language. Of course, there is nowhere near a universal consensus on what the biggest issues are, but here's what they are to me in order of importance (and I'm not alone):
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.
> "zero-cost abstractions"
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.
We did not though that due to C++, we already though that with languages like PL/I, Mesa, Cedar, Modula-2, Object Pascal, Ada, among others.
Given their level of adoption, those languages represented what their creators thought, not necessarily what the industry thought.
Same applies to Zig, which without something comparable to how UNIX, OS X, Windows SDK, iOS, Docker, among others have forced industry adoption of specific languages, Zig will have as much industry adoption as those languages, just another D or C3.
Maybe Oracle could make it unavoidable on JVM, instead of keeping to use C and C++ on the runtime.
I don't claim Zig represents what the industry thinks. The sharply declining use of low-level languages for high-level applications, however, shows that that idea is certainly unpopular these days. It could still be the case that more people will favour the C++/Rust style of zero cost abstractions even for low-level programming. I make no prediction there.
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.
Which is exactly the direction I see going forward, finally getting mainstream mindshare closer to how Xerox PARC languages were bootstraped, languages like Zig come about 30 years too late.
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.
> hardly questionable its adoption in the industry at scale.
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.
I've seen rust enter every major c++ codebase I've worked on in the last few years. The major thing slowing adoption is the lack of good interop with c++, and general dirth of greenfield projects that can afford to ignore existing c++ ecosystem of internal libraries. Hiring for rust skills is also a challenge. But still adoption presses on. I see a hockey stick curve still approaching.
Yes really, I gave you the examples from industry giants.
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.
I don't know what you're saying about Zig. I have no predictions about that language's success, I just think its design is very interesting.
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.
For me its simply better C, and the stdlib is pretty well designed overall
Check out Carbon, its the Kotlin of C++ ;)
I am not a C++ guy, but when Carbon is finally stable and hits the mainstream, I will definitely start trying out Carbon.
https://github.com/carbon-language/carbon-lang
Everyone talking about Carbon has to remember it is foremost for Google's internal migration purposes.
The way I see it, it's for people who want a more modern C, but not C++.
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).
C2 is still in development [0] and in my opinion sticks most closely to C in spirit. It seems like the best way to modernize a C project incrementally because it sticks most closely.
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.
[0] http://c2lang.org/site/introduction/evolution/
Odin
I don't count Odin as a modern C, because it is IMHO too different syntaxically to fit that description.
I disagree. Maybe in syntax it's a bit different but in spirit I think it's absolutely a modern C. Purely procedural code and manually memory managed. On top of that Ginger Bills stated goal for the project is to basically grind down all the rough edges off C.
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.
It is basically Modula-2 (in features) revamped with C syntax, and with compile time execution support.
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.
It's a powerful alternative to Rust and C++ for writing ultra low latency code when safety isn't important, like games or HFT. Its standard library and ecosystem have excellent support for passing around allocators and no hidden dynamic allocation (every function that allocates takes an allocator as a parameter), which makes it much harder to hit the latency pitfalls common to Rust and C++. It also encourages the latency-optimal approach of using local bump-a-pointer arena allocators where possible rather than the slow global allocator. And finally, the superior metaprogramming support makes it more convenient to use high performance techniques like struct-of-arrays.
Rusty rust and C++-y C++ are both often slower than hand-rolled C for a given function, and zig is intended to be a better way to hand-roll some C.
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.
Rusty rust?
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.
Idiomatic "low level" rust clocks in at about 10-50% slower than hand-coded C every time I try it. It is also about 10x easier to write the Rust code. Unsafe is just required a lot of the time. Sometimes it's code size or struct size just being larger to express a similar concept. To get back your performance you have to do things that are un-idiomatic (but you have to do in C anyway).
That is an unbelievable claim.
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.
It sounds like you work with people who don't really know C. Understanding how to pack a struct is a pretty basic skill. Write an optimized database or network stack without unsafe for me.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
It takes some hubris to post "rust is consistently 10% slower than C" take and back it up with a page which shows a result 6:4 in Rusts favor.
I said "every time I try it" and I said "idiomatic Rust." The fast rust implementations are consistently starred there, indicating use of hand SIMD or unsafe or others. If you read them, they are not very idiomatic.
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.
It just fundamentally does not make sense to compare languages by comparing codegen backends. GCC and LLVM do not produce the same code for equivalent code, especially when optimizations are applied. It's an apples-to-oranges comparison.
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.
I know what you said. I just don't think it was interesting. If by idiomatic rust, you mean generic "unoptimized" Rust being slower than optimized C, then yeah. No shit.
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.
I did not say “never”, I said “barely ever”.
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.
Rust versus C clang :-)
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
I also did not say "always," I said "every time I try it." The benchmarks game is a public example of this, with well-optimized implementations in all languages.
Why can't people just take the win of "10% slower, 10x easier"?
[dead]
Show examples please.
> Rusty rust and C++-y C++ are both often slower than hand-rolled C for a given function
This makes no sense whatsoever and very far from the truth.
Your comment was corrected or written by ChatGPT, right? It's super interesting that I can recognize these things now. The specific usage of punctuation, certain words and sentence construction.
"Safety" is always important, and you can write safe software in Zig.
“Safety” as defined in the context of the Rust language - the absence of Undefined Behavior - is important 100% of the time. Without it, you are not writing programs in the language you think you are using.
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.
curious, where is the definition of "undefined behavior" for rust specified?
Here: https://doc.rust-lang.org/reference/behavior-considered-unde...
mmm, no, that's an explicitly incomplete list of informally-described observable behaviors that qualify as undefined -- which is fine and good! but quite far from a specification!
Safety not important in HFT? You'd better make sure those precious microseconds buy you enough to make up for when things go awry.
Also, modern online gaming with microtransactions isn't something I'd entrust to "hold my beer" languages and gaming industry development practices.
Crashes from safety bugs are rare in HFT because they can replay years of data against code changes. For a strategy that trades in and out of positions quickly and is flat most of the time, it's also often not a big deal if the program crashes in the midst of running, as long as some technique has been arranged to cancel resting orders and alert a trader (who is generally monitoring the system's operations at all times).
They're certainly not inclined to pursue safety at any expense of performance in their code.
>Safety not important in HFT? You'd better make sure those precious microseconds buy you enough to make up for when things go awry.
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).
> modern online gaming with microtransactions
I don't think anyone should develop such games either
> Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar?
For me that sounds like a rather good value proposition. Too bad Zig never got the stackless corountine part they promised in the start.
Simpler, modern C with better tooling and less undefined behavior.
Zig's pointless choice to avoid global constructors - something all platforms have supported for several decades by now - makes I/O extremely unwieldy. That alone prevents it from being a viable mainstream language.
There is a lot of useful technical work and ideas in it though.
Being the anti Rust alternative for people who has spent years/decades accumulating weird knowledge about the inner workings of C and/or C++ and maintain that being able to shoot your feet off at a distance when doing the wrong incantation is a critical feature to have.
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.
https://github.com/oven-sh/bun/issues?q=Segfault
Or Rust being the anti Zig alternative for people who have spent years/decades accumulating weird knowledge about the finer details of type systems and maintain that not being able to express an algorithm, or review one, without consulting a language lawyer (or becoming one) is a critical feature to have and that build times don't matter.
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.
How is Rust anti zig if it came first?
It was a joke premised on the implicit assumption that Zig must be an "anti-Rust" because it came later. Maybe you could call different approaches contrarian if Rust had achieved some great popularity or consensus, but it hasn't. Rust's adoption rate is low because many don't find it enticing enough, and so it's unsurprising that there are several other approaches in the space of low-level programming - which is due for some update - that are all different from each other. Their attempts to improve on C and C++ in different ways don't make them "anti" anything else.
Ron Presler (the person you're responding to) is pathologically anti-Rust since before the birth of Zig.
Oh, I'm very pro Rust. I think that its use of the borrow checker is inspired and quite spectacular, that we can learn a lot from it. I just don't like it (as a practical programming language). It's not for me and for people who have similar preferences.
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.
> Oh, I'm very pro Rust.
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.
Oh, I didn't mean to touch a sore spot, I just assumed that by now it was obvious to everyone that a highly-marketed 10+-year-old language with less than 2% market penetration is unlikely (at least based on historical trends) to meet even the modest goal of half of the low-level software market (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).
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.
> Oh, I didn't mean to touch a sore spot
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.
Ten years in, Rust jobs are barely 10% of C or C++ jobs, if that. In any market segment, that is not the kind of adoption that successful products usually display.
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.
> Ten years in, Rust jobs are barely 10% of C or C++ jobs, if that. In any market segment, that is not the kind of adoption that successful products usually display.
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 ;).
Chill out kiddos.
There is plenty of room for both languages to exist. Engineering is all about trade offs. Rust has some big pluses but it's not suitable for every application.
To be fair, nodejs has 36 open, 474 closed:
https://github.com/nodejs/node/issues?q=Segfault
Which is written in C/C++. Showing that Zig is not moving the needle on UB when a project becomes sufficiently complex.
Take a look at Deno and check the percentage coming from FFI with unsafe languages.
https://github.com/denoland/deno/issues?q=Segfault
People keep thinking that even though Microsoft, Apple, Google, etc. with all the incentive and tooling in the world couldn't evade one of the few replicable results in programming languages (people can't reliably write memory safe code in memory unsafe languages), somehow with Zig it will be different. It's honestly a pretty fascinating phenomenon to me because most of these people are smart, and some of them are even ostensibly in the security community.
It's not that they think zig will avoid the issues, but rather that the cost required to do so is too great, so they would rather have a nicer language with more traditional ways to catch those bugs. If things like memory tagging continue to take off, hardware will catch these issues anyways. I don't personally agree but they are allowed to have their opinions.
More than memory safety, I do think thread safety is a bigger challenge I'd love more modern languages to tackle.
We have language groupies now, like how teenagers have their favourite k-pop bands, I wouldn't take it all so seriously. Security has a tendency of making itself undeniable, it's lessons will be learned one way or another by everybody without exception.
AESPA
The question that matters is how many deno has.