Zig is a nice language, but those articles always compare new languages against old-style C without use of modern tools. Most of the listed advantages you can have in C as well if you are willing to adopt modern tooling and style: signed overflow checking: sanitizers, errors you can not ignore: [[nodiscard]], slice type which know their size: variably-modified types or span types.
Defer will also appear in C compilers soon, but personally I still think goto-error handling is clearer.
(Rust has an advantage for temporal memory safety, but this does apply to Zig.)
It seems that part of what Zig is trying to do, though, is create a pit of success around these practices. So the response might be something like, “Yes you can do these things in modern C, but doing it consistently requires more discipline than we’d like.”
IMO you cannot fairly compare static analyzers/sanitizers with features baked into the language/compiler.
Though I've noticed the same trend when reading a famous Rust primer for C++ developers. Like there are obviously so many good and valid arguments when comparing the two languages that would've gotten the point across. Yet the authors felt the need to push it one step further, where the comparison no longer seems fair. Like comparing Rust with C++17 when C++20 provides the same exact feature that Rust claims to provide.
As soon as you have dependencies you are dealing with however the authors decided to build things.
Part of why languages exist is just to get a new ecosystem.
At this point, you could fork C/C++, only remove features, give it a new name, a new package service, and maybe fork the standard library, and you could end up with something pretty competitive against Zig or Rust.
I don't see why this requires not having dependencies.
Yes, new languages try to create a new ecosystem. I think this is a bad thing - we already have too many of such - often somewhat isolated - language ecosystems. But I also do not think we need new ecosystems, when we can evolve the existing one. I have seen C evolve quite a bit over time, so the idea that we have to create new ecosystems to solve problems is wrong in my opinion. C evolves very slowly, which means that some things need more time, but I also think that it is generally a very good thing that it evolves slowly.
But Zig is expressly not trying to bootstrap a completely new ecosystem. Integrating with - and depending on - existing C and C++ code is a core use case. So much so that they’ve adopted “maintain it with Zig” as a motto that intentionally puns on “rewrite it in Rust”.
I’ve settled on a dialect of C++ for systems programming after using C for a long time. It’s mostly C-like and I disable exceptions, RTTI, etc. but I do use templates, overloads, methods, lambdas, etc.
I have my own object system with constructor methods that all return a status code so you don’t need exceptions, my own stdlib for containers, buffered I/O, networking, hashing, math, threading, async, etc.
C++ gives you all the features to effectively build your own language, and you can use first class tooling since C++ is widely supported. LLMs also make it much easier to build out and test an entire stdlib on your own.
I've essentially done much the same. One of the more under-rated features of C++ is being able to build a new language environment based on a different set of composable idioms from the low-level primitives on up.
C++ is as much a tool for building nice systems DSLs as it is a systems language. The heavy investment in compile-time expressiveness has really paid off for the language over time.
Also, Zig is as at least as expressive as C++ (but without the implicitness and general language complexity that makes reviewing some sensitive code, where you need to see exactly what operations are performed, hard), and it supports arenas better than C/C++/Rust.
Seems like a long way to walk though. Retrofitting this will take time (if it'll ever complete).
Zig made it a core part of the language and library. I'll assume Rust will make it farther than C++ ever made it, but just take a look at how retrofitting custom allocators is going there.
Seems like it will be useful for use-cases like embedded where you're restricted to certain parts of the library anyway. But the battle is kind of already lost for support at the level of Zig or Odin. Even if they retrofitted support for the whole standard library, they'll never be able retrofit all crates or make people even bother adding support for all new crates.
> Seems like it will be useful for use-cases like embedded where you're restricted to certain parts of the library anyway. But the battle is kind of already lost for support at the level of Zig or Odin.
Odin in particular does a simply terrible job here. Take the most common need for allocations, a growable array type, in Rust Vec<T> and in Odin dynamic[T]
In Rust we only pay extra to store the allocator metadata if there is allocator metadata. If we're content using the general purpose allocator Global with global metadata it's free. In Odin we always need to pay to store an "allocator proc" function pointer and a (possibly unused) metadata pointer, so that's 2x machine word worse for Odin. We pay this even if we never allocate, and indeed even if we can't allocate, whereas of course in Rust that's free.
But then when we do need to allocate, in Rust that's a static dispatch unless our allocator specifically wants dynamic dispatch. So again for Global it's just a static dispatch. But in Odin it's always a slower dynamic dispatch.
The upside? To the extent there is one it's probably the New Jersey style, ie it was simpler to implement Odin. Which is a benefit to Ginger Bill, but not to you as an Odin programmer.
Rust's Allocator APIs have been around since 2016, less than a year after 1.0, they're just now stabilized.
The stdlib types that allocate have been generic (with default generic parameters) over the underlying Allocator used for a very long time. All widely-used data structure libraries where it's feasible/reasonable to use other allocators also are already generic over the Allocator.
It won't "take time to retrofit" because the language and ecosystem have already been prepared for it for 10 years. For context, async syntax was introduced a few years after that and if you just started learning the language today you wouldn't notice it wasn't there in 1.0.
Seems like I've misread the recent Rust version announcement:
> This release brings about the stabilization of the core parts of allocator_api, enabling library authors to define custom allocators that can be used together with certain standard library types - currently Vec and Box. These are enabled through the newly-stabilized Allocator trait.
That made it sound like it was rather limited currently.
I asked an LLM (because it's outside my expertise) and it said:
> It is fair to say that the heaviest architectural lifting is already done: adding a defaulted type parameter (A: Allocator = Global) preserves backward compatibility for existing code, and the core data structures already store and thread the allocator internally. However, plumbing that generic parameter through String, HashMap's std wrapper, and hundreds of standard library methods still represents substantial retrofitting work rather than a completed state.
Looks like The patch notes lead me a bit astray. But it's also not at an 'already all there' state either.
In critical low-level code, any kind of overloading - operator or otherwise - is something you'd rather not have.
By expressivity I don't mean what characters you use in the conrecte syntax, but the number of lines needed to express an algorithm (up to a small constant). C doesn't have C++'s expressivity because it lacks templates, and while you can sort of express that kind of thing with macros, it's not all the way there. Zig, however, gets you all the way there (you might need to write matrix_plus instead of +, but the expressivity is the same).
BS. Using operator overloading with SIMD makes it easier to translate algorithms into code. I wrote my own U8x32 wrappers and a + b is way better than a.add(b).
I'm not disputing that some people like user-controlled operator overloading (Zig does have + etc. for vectors), but clearly others prefer no user-controlled overloading of any kind (don't know what the LLMs prefer, if they have any preferences at all). In the safety-critical space where I once worked, where people could get hurt or die if there's a stack overflow, the more common preference was against (user-controlled) overloads or any implicitness. That's why we need options.
Many people are against operator overloading, imo my only issue with C++ operator overloading is that you're allowed to overload the the assignment operator. From what I can see this is the root of many issues
Is there a way to support varying the meaning of "+" etc without introducing a lot of complexity? I suppose if Zig had nested functions, and the ability to define a nested function called "+", then you could have name shadowing instead of "overloading".
OCaml basically gives you operator overloading this way without actually doing overloading. I'm wondering why we can't have these OCaml-isms in other languages - without needing to use OCaml - which sadly comes with other commitments.
All these new languages are unreadable relative to C. If, like me, you like explicit stuff like for (size_t i = 0; i <= n; i++) total += a[i]; all these new languages won't do it.
Funnily, Zig does allow doing it explicitly like that, just need use while rather for:
var i: usize = 0;
while (i <= n) : (i += 1) {
total += a[i];
}
That said, perhaps Odin, for which simplicity and readability is guiding principle in its design, is more up your alley. In Odin, can be read:
for i := 0; i <= n; i += 1 {
total += a[i]
}
Exactly same style can be used in Go & V (which is/was? quite infamous here in HN). But in all languages, for this example at least, a foreach-like iteration, i.e.
I don't like this explicitness, because very often it's a lie. In the times of PDP-11 that would compile into a literal counter and literal ADD, DEC, and BNE instructions. Now it will most often compile into some vectorized semi-unrolled form with seven-letter instructions like VPHADDD which add many integers at once, etc.
If I want specific instructions to be run in a specific order, like touching hardware registers, I reach for intrinsics or assembly. If I want an array summed, I prefer to express the intent: total = the_array.sum(); I leave the implementation to the compiler / stdlib.
I honestly don't think total = a.sum() is any less explicit than for (size_t i = 0; i <= n; i++) total += a[i]. If anything, a.sum() is more explicit as at least it expresses the programmer's intention explicitly. The loop is one more layer between the reader and the writer's intention, without faithfully reflecting what happens on the bare metal. So it's the worst of both worlds.
God I loved playing around with D back in the day when I was in high school. It seemed like a no-brainer that it was going to be huge. It's such a shame it never took off. Incredible language.
It's so damn nice, its a shame it's never taken off the way it could. I think there's still time to make it attractive to companies, but with people's increasing use of AI I don't think anyone even cares what language their model writes in, look at the insane uptick in Rust programming.
I try D almost every year, but I've never really gotten a working IDE environment with it. I'm not sure if it's issues with being on Windows or just the LSP not being that great. I really wish D was adopted as widely as Go.
It’s pretty obvious why they didn’t, they’re GC by default. That’s already enough to put people off, even if it’s “not a problem” in reality, people will just avoid it for systems programming if they hear that, they will assume all the good features need the GC
I like both of those, I like the idea of Zig, it does seem to be striving to be pure in some areas where C is "king" that other languages gloss over, but Zig is always changing, and its got some elitist people in its ranks that left me not wanting to bother with it. Imagine a programming language maintained and used by geohot clones.
It's okay for me to declare a macro with `__attribute__((warn_unused_result))` for GCC and Clang, and `[[nodiscard]]` when the C code is later compiled with C++ (or nothing).
C is far behind the sate-of-art in C and Go families. True, but not bad.
It is what it is, but can work on what it already has, while keeping its tradition.
Small changes, add common extensions, conservative additions, improve coherence and correctness of the standard while keeping easy to implement and small.
No crazy things.
Keep in mind that it is standardized and targets things others do not target.
AI slop. Every article on this site has "The honest tradeoff" as a header. Looks like it was generated to promote a book which is no doubt also just slop.
> Every article on this site has "The honest tradeoff" as a header.
This is a hallucination. I'm sorry. This is what we call these kind of statements these days. Unless you can prove your humanhood, that's how it is now.
I wrote recently about a weird issue I encountered with Zig, though to be fair it was related to using Zig to compile C code, humorously in a Rust project (which touches on all of the languages mentioned in this post).
While I did just dismiss it as an edge issue, it turns out that this same rather clumsy sort of mistake has happened repeatedly in Zig's pure rewrite of MUSL. And despite being an absolutely catastrophically bad problem, by my judgment, the problem is still in main at this moment, across a wide number of musl function rewrites.
Which gives me pause about the whole zig project. If you're rewriting a critical library, making such simple but consequential mistakes shouldn't happen, and if they do happen it should be a red alert type situation.
Zig can be a hobby/learning project (in which case these elementary mistakes, and the lax development process that allowed them, are totally acceptable), or it can be a project that targets critical applications (like TigerBeetle, which handles REAL MONEY), but it can't be both.
When working with Zig, you are a beta tester. The development process is unfortunately not great, so bugs slip in fairly easily. You need to be ready for it and test your application properly. Large Zig projects don't target the latest version. That said, if you can deal with that, you get a great language that is fun to use and very practical. I think it's worth it, even if it can be frustrating at times.
Personally I think it's not that catastrophic for zig < 1.0. Just a performance regression, and one can always link to other libc implementations, or is their own implementation enforced now?
If errors like this are acceptable because of the version number of an otherwise decade old project, then that's ample evidence of why Zig is not ready and should not be used for any software that needs surety.
You know that GNU libc to this day essentially calls strlen() on every call to sscanf(), which is pretty much the same issue? And that this behaviour, present in many other implementations of standard C library (including Microsoft's), was responsible for e.g. slow JSON parsing in some very popular online games [0]? Does that mean glibc is still not production-ready?
sscanf is quadratic in the worst case, and has been flagged along with the bulk of the rest of the libc string support as being hazardous or potentially harmful. Its continued existence is for compatibility, but new projects should not use it.
A version number starting with 0 is not just evidence, but a direct statement by the maintainer that software is unstable/pre-release no matter how long it has been in development.
It isn't my thing though. It's quite literally, by choice, their thing. They are the ones who decided that rewriting musl in zig was something they need to do and was such a priority. Only it's a serious regression.
But I mean, the six people in a trenchcoat comment is basically precisely what should give people pause. In my project I simply eliminated zig from the stack entirely because even if I worked around the problems, what comes next? What's the next showstopper that gets waved away as oh well six people in a trenchcoat...
Some people (not its creators) talk about Zig as if it's anywhere near production ready. It's fine to be excited about it (there's a lot to be excited about), but we gotta be realistic.
This submission is advocating Zig over C for system programming. I pointed out a pretty significant reason why maybe you should pause that decision for a bit, and the response have been much more significant reasons why you should be wary.
Now it's "FUD", also it's a beta and you're a beta tester, and it's 0.x, and look they disclaim that you shouldn't trust it, and barely anyone works on it, and... By the advocates for the language, it should be noted.
This is a bizarre thread. These very comments are precisely why it should give pause (which isn't remotely "FUD", and what an utterly asinine claim). Zig looks neat and it might get there, but this absurd apologism and goalpost moving is not convincing to adopt the language.
Again, in a submission advocating using Zig for system programming.
llm_nerd: "I found a bug. This gives me pause about the whole zig project"
I don't see how the latter is a fair reaction given the former. Especially since they only recently started working on the libc port (although it had been talked about for much longer)
They have been cooking for over ten years. It is more than fair to say at this point that they are not capable of shipping a stable, reliable, fast and efficient compiler. It is fundamentally flawed and I could easily write thousands of words explaining why from the architectural design to the development process.
Zig hides behind its pre 1.0 status to justify poor decision making while simultaneously actively trying to attract attention through marketing. That attention translates to resources and influence that are undeserved on the technical merits.
The dudes name is "llm_nerd" its not worth engaging lol. These are the same people that saw the bun rewrite in rust break tls and fail open and shrugged.
I don’t get it, C arrays can be used as slices, no?? Given a pointer and a length, which is how C does any array, works just as well (I mean if you consider arrays without a length a fine thing) as a slice!
"C is not going away and I still read a lot of it, because the UNIX source code and most system libraries are written in C and their man pages document them with C prototypes. But for new code I choose Zig."
Has this aged well though?
The TechBros pour in tons of money into "agentic programming" or "agentic workflows" right now. You can see that all over the place; OmarchySlop and other AI-controlled projects, where Claude is now the main designer. So in such a scenario, where does Zig really fit in? The "but for new code I choose Zig" is not a really compelling argument IMO. It reminds me of the issues that D has ("we are the better C++!!!" or even Java too). It's interesting that so many languages try to replace C. All failed, IMO. And C is still a pretty bad language. For instance, I think almost everyone would concede that crates in Rust are useful or good; C++ kind of submitted to this and has their own variant now as far as I know. C does not - or perhaps it has but almost nobody would know it.
I kind of want a language that really sits like in both camps: compiled, and scripting use. But each language seems to just fail hard in one area. Including syntax-wise. Complexity-wise too; I find Rust annoyingly complicated. Go is in many ways simpler than Rust, but it sucks in other ways. Of course there are always trade-offs either way, but I kind of want a language that can offer insane speed while having a great syntax (crystal also fails here; it is fast but the syntax is pretty bad. Why is "alias xyz abc" not working? It's so easy to support. But anyway I could go on for years here.)
My goto language for both fast and still scriptable is Dart. They invested a lot in UX and performance in the last few years and it shows. Run as a script or compile to a small binary that runs pretty fast, similar to Go performance as as as I have bothered to check. Best DX out there even if you don’t care about Flutter.
Rust will take over all these niche languages anyway. Yes, Rust is a viable replacement for C and C++ in the long term. Zig is just trying to be a middle ground, which we've established doesn't work. Zig is particularly irrelevant compared to Rust in the LLM era.
Their rewrites of all security critical libraries while also refusing to use AI which at the moment is surfacing huge vulnerabilities all over the place.
Defer will also appear in C compilers soon, but personally I still think goto-error handling is clearer.
(Rust has an advantage for temporal memory safety, but this does apply to Zig.)
https://blog.codinghorror.com/falling-into-the-pit-of-succes...
Though I've noticed the same trend when reading a famous Rust primer for C++ developers. Like there are obviously so many good and valid arguments when comparing the two languages that would've gotten the point across. Yet the authors felt the need to push it one step further, where the comparison no longer seems fair. Like comparing Rust with C++17 when C++20 provides the same exact feature that Rust claims to provide.
As soon as you have dependencies you are dealing with however the authors decided to build things.
Part of why languages exist is just to get a new ecosystem.
At this point, you could fork C/C++, only remove features, give it a new name, a new package service, and maybe fork the standard library, and you could end up with something pretty competitive against Zig or Rust.
Yes, new languages try to create a new ecosystem. I think this is a bad thing - we already have too many of such - often somewhat isolated - language ecosystems. But I also do not think we need new ecosystems, when we can evolve the existing one. I have seen C evolve quite a bit over time, so the idea that we have to create new ecosystems to solve problems is wrong in my opinion. C evolves very slowly, which means that some things need more time, but I also think that it is generally a very good thing that it evolves slowly.
I have my own object system with constructor methods that all return a status code so you don’t need exceptions, my own stdlib for containers, buffered I/O, networking, hashing, math, threading, async, etc.
C++ gives you all the features to effectively build your own language, and you can use first class tooling since C++ is widely supported. LLMs also make it much easier to build out and test an entire stdlib on your own.
C++ is as much a tool for building nice systems DSLs as it is a systems language. The heavy investment in compile-time expressiveness has really paid off for the language over time.
Rust just stabilized its `Allocator` API in version 1.100.0. Definitely worth checking out!
Seems like it will be useful for use-cases like embedded where you're restricted to certain parts of the library anyway. But the battle is kind of already lost for support at the level of Zig or Odin. Even if they retrofitted support for the whole standard library, they'll never be able retrofit all crates or make people even bother adding support for all new crates.
Odin in particular does a simply terrible job here. Take the most common need for allocations, a growable array type, in Rust Vec<T> and in Odin dynamic[T]
In Rust we only pay extra to store the allocator metadata if there is allocator metadata. If we're content using the general purpose allocator Global with global metadata it's free. In Odin we always need to pay to store an "allocator proc" function pointer and a (possibly unused) metadata pointer, so that's 2x machine word worse for Odin. We pay this even if we never allocate, and indeed even if we can't allocate, whereas of course in Rust that's free.
But then when we do need to allocate, in Rust that's a static dispatch unless our allocator specifically wants dynamic dispatch. So again for Global it's just a static dispatch. But in Odin it's always a slower dynamic dispatch.
The upside? To the extent there is one it's probably the New Jersey style, ie it was simpler to implement Odin. Which is a benefit to Ginger Bill, but not to you as an Odin programmer.
The stdlib types that allocate have been generic (with default generic parameters) over the underlying Allocator used for a very long time. All widely-used data structure libraries where it's feasible/reasonable to use other allocators also are already generic over the Allocator.
It won't "take time to retrofit" because the language and ecosystem have already been prepared for it for 10 years. For context, async syntax was introduced a few years after that and if you just started learning the language today you wouldn't notice it wasn't there in 1.0.
> This release brings about the stabilization of the core parts of allocator_api, enabling library authors to define custom allocators that can be used together with certain standard library types - currently Vec and Box. These are enabled through the newly-stabilized Allocator trait.
That made it sound like it was rather limited currently.
I asked an LLM (because it's outside my expertise) and it said:
> It is fair to say that the heaviest architectural lifting is already done: adding a defaulted type parameter (A: Allocator = Global) preserves backward compatibility for existing code, and the core data structures already store and thread the allocator internally. However, plumbing that generic parameter through String, HashMap's std wrapper, and hundreds of standard library methods still represents substantial retrofitting work rather than a completed state.
Looks like The patch notes lead me a bit astray. But it's also not at an 'already all there' state either.
By expressivity I don't mean what characters you use in the conrecte syntax, but the number of lines needed to express an algorithm (up to a small constant). C doesn't have C++'s expressivity because it lacks templates, and while you can sort of express that kind of thing with macros, it's not all the way there. Zig, however, gets you all the way there (you might need to write matrix_plus instead of +, but the expressivity is the same).
OCaml basically gives you operator overloading this way without actually doing overloading. I'm wondering why we can't have these OCaml-isms in other languages - without needing to use OCaml - which sadly comes with other commitments.
If I want specific instructions to be run in a specific order, like touching hardware registers, I reach for intrinsics or assembly. If I want an array summed, I prefer to express the intent: total = the_array.sum(); I leave the implementation to the compiler / stdlib.
https://github.com/buggins/dlangide
Check out Nimony effectively Nim 3.0 from the author. It's a top to bottom rethinking of Nim with all the lessons learned. I'm so hyped about it tbh
https://nim-lang.org/araq/nimony.html
It's okay for me to declare a macro with `__attribute__((warn_unused_result))` for GCC and Clang, and `[[nodiscard]]` when the C code is later compiled with C++ (or nothing).
It is what it is, but can work on what it already has, while keeping its tradition. Small changes, add common extensions, conservative additions, improve coherence and correctness of the standard while keeping easy to implement and small.
No crazy things.
Keep in mind that it is standardized and targets things others do not target.
https://www.pangram.com/history/5f3d749c-713c-447a-82cc-d3a6...
I'm not ideologically against AI, but I'd certainly not buy a book from someone who needs to use AI to write like an article like that...
[0]: https://www.mtsoukalos.eu/2026/04/why-zig-over-rust-for-syst...
Meanwhile no one's pointing out any technical errors.
This is a hallucination. I'm sorry. This is what we call these kind of statements these days. Unless you can prove your humanhood, that's how it is now.
https://dennisforbes.ca/blog/microblog/2026/10/the_accidenta...
While I did just dismiss it as an edge issue, it turns out that this same rather clumsy sort of mistake has happened repeatedly in Zig's pure rewrite of MUSL. And despite being an absolutely catastrophically bad problem, by my judgment, the problem is still in main at this moment, across a wide number of musl function rewrites.
Which gives me pause about the whole zig project. If you're rewriting a critical library, making such simple but consequential mistakes shouldn't happen, and if they do happen it should be a red alert type situation.
https://codeberg.org/ziglang/zig/issues/37402
Looks like it is being worked on.
Personally I think it's not that catastrophic for zig < 1.0. Just a performance regression, and one can always link to other libc implementations, or is their own implementation enforced now?
[0] https://news.ycombinator.com/item?id=26296339
I did not say it's acceptable, just not catastrophic, especially since workarounds exist.
I've used zig in similar capacity in production in the past and personally I would take the slowdown just to avoid dealing with MSVC :)
https://ziglang.org/download/0.17.0/release-notes.html
> Zig has known bugs, miscompilations, and regressions.
> Even with Zig 0.17.x, working on a non-trivial project using Zig may require participating in the development process.
> When Zig reaches 1.0.0, Tier 1 support will gain a bug policy as an additional requirement.
> I made the judgement call to let this slide in the review. I'm still not sure whether it was the right or wrong call.
https://lobste.rs/s/lh1j0e/shlemiel_painter_is_back_how_zig_...
The whole zig project is like six people in a trenchcoat. You can't expect them to prioritize your one thing after 3 weeks
Did you make a PR?
https://codeberg.org/ziglang/zig/issues/37402
But I mean, the six people in a trenchcoat comment is basically precisely what should give people pause. In my project I simply eliminated zig from the stack entirely because even if I worked around the problems, what comes next? What's the next showstopper that gets waved away as oh well six people in a trenchcoat...
Eh, whatever.
https://ziglang.org/documentation/master/std/#std.mem.findSe... didn't exist then, now it does.
And if i may quote from https://ziglang.org/download/0.17.0/release-notes.html:
> Zig has known bugs, miscompilations, and regressions.
> Even with Zig 0.17.x, working on a non-trivial project using Zig may require participating in the development process.
> When Zig reaches 1.0.0, Tier 1 support will gain a bug policy as an additional requirement.
If you're not willing to participate in the development process, then you should wait or use something else.
Some people (not its creators) talk about Zig as if it's anywhere near production ready. It's fine to be excited about it (there's a lot to be excited about), but we gotta be realistic.
Now it's "FUD", also it's a beta and you're a beta tester, and it's 0.x, and look they disclaim that you shouldn't trust it, and barely anyone works on it, and... By the advocates for the language, it should be noted.
This is a bizarre thread. These very comments are precisely why it should give pause (which isn't remotely "FUD", and what an utterly asinine claim). Zig looks neat and it might get there, but this absurd apologism and goalpost moving is not convincing to adopt the language.
Again, in a submission advocating using Zig for system programming.
llm_nerd: "I found a bug. This gives me pause about the whole zig project"
I don't see how the latter is a fair reaction given the former. Especially since they only recently started working on the libc port (although it had been talked about for much longer)
Zig hides behind its pre 1.0 status to justify poor decision making while simultaneously actively trying to attract attention through marketing. That attention translates to resources and influence that are undeserved on the technical merits.
Alright then go for it, hotshot. We're waiting.
The lack of a native slice is the most glaring C fault I think exists
(And of course the committees won't implement it, and of course C is going to remain broken)
But I am also quite happy about how far one already gets with variably modified types and a custom span type: https://godbolt.org/z/rPen5Movd
Has this aged well though?
The TechBros pour in tons of money into "agentic programming" or "agentic workflows" right now. You can see that all over the place; OmarchySlop and other AI-controlled projects, where Claude is now the main designer. So in such a scenario, where does Zig really fit in? The "but for new code I choose Zig" is not a really compelling argument IMO. It reminds me of the issues that D has ("we are the better C++!!!" or even Java too). It's interesting that so many languages try to replace C. All failed, IMO. And C is still a pretty bad language. For instance, I think almost everyone would concede that crates in Rust are useful or good; C++ kind of submitted to this and has their own variant now as far as I know. C does not - or perhaps it has but almost nobody would know it.
I kind of want a language that really sits like in both camps: compiled, and scripting use. But each language seems to just fail hard in one area. Including syntax-wise. Complexity-wise too; I find Rust annoyingly complicated. Go is in many ways simpler than Rust, but it sucks in other ways. Of course there are always trade-offs either way, but I kind of want a language that can offer insane speed while having a great syntax (crystal also fails here; it is fast but the syntax is pretty bad. Why is "alias xyz abc" not working? It's so easy to support. But anyway I could go on for years here.)
And of course it needs to get to stable first