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.
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.
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.
First of all, sscanf doesn't need to be quadratic in the worst case; it absolutely can work without finding the NUL-terminator first. Second, I'd like to see that list of "flagged along with the bulk of the rest of the libc string support as being hazardous or potentially harmful" functions. Does this list include strchr()? Because if yes, your original argument fails to stand.
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.
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.
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.
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.
Up until about a week ago, I had no sympathy for people complaining about "AI writing style" in articles - and then all of a sudden it hit me. Kind of like unexpectedly developing an allergy to sawdust.
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!
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.
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.
Yes, there are definitely other use cases that Zig doesn't support (which some may view as a good or bad thing). I just wanted to respond to the comment about basic SIMD since the example was U8x32 and operator+, which Zig can do.
It's not that Zig can't do it; Zig has been carefully designed to prevent it from being done as one of its core values, which is something that's important to some people just as the ability to do it is important to some other people. Supporting it or preventing it both have pros and cons for different users and different uses.
To be fair, the impression is that you want to do low level systems programming in Rust. It's a fine preference but it does put you in a different audience
I’ll admit I interpreted that “you” in pron’s sentence to be a colloquial “you” and not an imperative one. So, more of a statement of their own preference than a strong statement of how things should be.
The point is, it’s a tradeoff. With overloading, exactly which code executes on a specific line becomes a bit more implicit because it depends on extra information from the surrounding context: the types of the arguments.
That comes with the usual tradeoffs. On the one hand, you could argue that the compiler is taking care of it for you, which saves the programmer from having to manually deal with it, and removes some visual clutter from the code.
But you can also argue that letting the choice of function be implicit means that a programmer who wants/needs to keep track of exactly what every line of code is doing needs to carry all that contextual information in their own head, too. For this programmer, it’s adding to the mental burden.
I don’t think it’s a coincidence that Kelley constantly brings up how Zig was inspired by difficulties writing a digital audio workstation with very hard real-time requirements. Part of what he’s doing there is giving a motivating case for why he wants to be an absolute control freak about, e.g., micro-managing exactly when memory is allocated and deallocated. That’s something only a subset of systems programmers need, because not all systems programming is dealing with things like hard real-time.
> The point is, it’s a tradeoff.
If it's a trade off it's highly squewed.
>But you can also argue that letting the choice of function be implicit means that a programmer who wants/needs to keep track of exactly what every line of code is doing
Use LSP/IDE then ctrl+click operator. Boom. You see what it's executing.
Idea is to create abstraction that make it easier to operate on a more complex level. If you need that level of micro-managing just stick to assembly.
C++ destroyed the good will here by simultaneously insisting that you're only supposed to use this feature to give types their natural operators (makes sense) and then inventing implausible new "natural" operators so that Bjarne can show off his new toy with the I/O streams.
I actually don't like Rust's choice to implement + for Strings but most people seem to accept that, however C++ goes ludicrously far beyond "I don't like it but some people do" and straight off the cliff into "Nobody thinks that's OK" leaving you to wonder why there was effort to implement this bad idea. For example C++ can overload the short-circuiting boolean operators... but the overloaded versions don't short circuit. So now you've made things dramatically worse!
Note that it's not that Zig is opposed to (user-controlled) operator overloading; it's opposed to (user-controlled) overloading of all symbols: The resolution of `foo` in `foo(x)` should not depend on the type of `x`. The issue is not the operators but the overloading, and Zig wants to prevent (user-controlled) overloading of any kind. This makes some things less convenient and other things more convenient.
> The resolution of `foo` in `foo(x)` should not depend on the type of `x`
This depends on how you're squinting at this word "resolution".
Remember on a modern CPU an XOR R1 R1 does not result in an ALU operation, the decoder understands this idiom and just renames a zero'd register as R1, whereas of course it can't do that for say XOR R2 R3 because that's an actual XOR operation. So if "resolution" means "exactly what happens on the CPU" apparently there is no such facility provided even in assembler.
So apparently we mean only that it should have, in some sense, the same effect. I think the fact Rust is OK with
It's not about okay or not okay. Zig is designed to prevent any user code from being implicitly called, or for the resolution of user code to be done implicitly. It's not about what the CPU does internally, but whether you're able to tell, from reading the code of a single subroutine, which operations could be done, whether stack frames can be created etc.. This has pros and cons, and for some people the pros outweigh the cons and for others, the other way around, and that's why different programming languages need to prioritise different things when they target different users. Just as Rust clearly isn't supposed to be best for all uses, neither is Zig, or any other language for that matter. Every language is meant to appeal to some and not others.
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
I’ve also experienced some unnecessary shenanigans related to blurring the distinction between primitive operations, and stuff that happens dynamically at run time such as method calls.
For a somewhat different example of the same general idea, look at how Java handles primitives and their boxed counterparts. = on two ints always compares their value. = on two Integers compares their pointers. But it uses flyweight instances for values up to 256, so in Java, whether two Integers with the same numeric value are equal according to the = operator depends on what that value is.
Then throw autoboxing and generics into the mix, and it suddenly becomes very easy to do refactorings that work fine in the unit tests (which tend to use small numbers) but fails in confusing ways in production.
This isn’t an example of operator overloading, of course. But I hope it more simply illustrates why, at least in certain problem domains, there’s value in being able to visually tell when surprising runtime shenanigans are and are not possible. And also to make it impossible to cross that boundary without touching all code that falls within the blast radius of that change.
> But it uses flyweight instances for values up to 256, so in Java, whether two Integers with the same numeric value are equal according to the = operator depends on what that value is. ...
I believe Java caches Integer objects for values -128..+128, not 256. But that may be an implementation detail, and not something to count on.
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.
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.
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.
Although it's true that all of Rust's standard library collections are generic over Allocator, Rust 1.100 only stabilizes useful allocator APIs for Box and Vec
If you want to use your MyCustomAllocator with a HashMap or a BinaryHeap or you've lost your mind and want a LinkedList none of that was stabilized yet.
Personally I am slightly interested in HashMap, VecDeque and String but I think Vec is much more heavily used than any of those and will illustrate just how thin the pickings are in this space for real.
Perhaps custom allocators could be interesting for BTreeMap and BTreeSet? I am not familiar with their internal implementation, but as I understand it those should allocate fixed-size blocks, which would benefit from a specialized fixed-size allocator.
Sure, in principle all of the standard library collections and indeed most 3rd party collections which allocate could benefit from providing a good Allocator API.
If there's a particular 3rd party collection you know would benefit, you could ask them, or write a PR to make use of Allocator. The standard library collections of course know people are interested, you can think of this as an MVP.
> 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.
Sounds like the Odin implementation isn't particularly optimal. My point wasn't about speed or good implementations. My point was about which languages make it practical to consistenly use custom allocators as a user of the language. Not just across your own code, but also code from the standard library and external packages.
I have no practical Odin experience, I just looked at the core concepts. I tried a bit of Zig and there's significant discipline in the standard library to enable allocator use. But in 3rd Party libraries this discipline is hard to enforce because it also makes it harder to design easy to use interfaces.
I'm interested where on the spectrum of allocator usability Rust will end up at. I'd expect it somewhere between Zig and C++
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).
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.
I've tried the intellij plugin and vscode extension. It never seems to work right. I remember there being lots of issues about not finding phobos/the standard library.
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.
If they can get the tooling situation handled better with 3.0, Nim will be probably the best all-around programming language in my book. The only reason I tend to opt for Zig instead (and the reason the library ecosystem is pretty small) is that it just feels a little unpolished all over the place. But the core principles are just so good.
I don't mean that as an insult to Zig. Zig is amazing. But the ergonomics of Nim are just unbeatable.
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
Nim is stack allocated by default, and you annotate types explicitly with `ref` to use the GC. Even then, the compiler elides reference counting using borrow checks, you can choose different GC options, and the GC isn't stop the world like most. You don't need to touch reference counting if you don't want to, and Nim fits embedded dev pretty well for that reason.
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.
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.”
Yes sir, with the right kind of discipline even assembly starts to look like luxury. With a heart that holds no fear, one can code in straight 0's and 1's.\s
These days I wonder what is harder:
1. problems of collective action or
2. communicating that reducing everything to collective action is the real issue.
Now explain why the collective action problem of moving everybody to Zig is easier than the collective action problem of improving C usage and tooling. IMHO the latter is far more realistic (and in fact a lot has already improved).
So, suppose a team - so hopefully a rather small instance of "everybody" - has decided to make some changes to how they work, and they're trying to decide between adopting Zig and changing their existing C coding conventions.
Suppose, also, that they have decided to make the change incrementally. So a rewrite is not in the cards.
The advantage of sticking with C that I see is that nobody has to learn a new language, migrate to a new toolchain, anything like that. So it is definitely the smaller change. But the downside is that it may be more difficult to hold the line. For some indeterminate (possibly indefinite) period of time you have a mix of legacy code that's being allowed to stay on the old conventions, and new/migrated code that's supposed to be held to the new conventions. IME one solo developer can maintain that distinction, but a team working in a business environment, possibly with people cycling on and off, will struggle with it. You can try to bake the distinction into your tooling, but that's often easier said than done. Most tools expect one set of conventions per project.
The advantage of adopting Zig that I see is that you set a clear demarcation line. New files will be written in Zig. Migrated code gets ported to Zig. Everyone knows that Zig has one coding standard, C has another coding standard. They look different, so it's easy to keep track of which is which. They each have their own compiler flags and static analysis tools, so it's hopefully easier to separate the legacy rules from the new ones.
Now, I mostly do cruddy business applications so I haven't actually done this with C and Zig. But I have done it on the JVM, and IME whether "modernize legacy Java in place" or "modernize legacy Java by strangler vining over to Kotlin" works better depends heavily on what the legacy code in question actually looks like and how much you want to change.
If you change languages, you have a clear demarcation line. I still would say that if you fail to introduce stricter coding standards on a C project once you made the decision to do so, you have bigger problems that simply using other languages will not solve. So don't think this reason alone is very strong.
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.
The obvious answer is that I don't want to pay for these checks at runtime and can catch most of these bugs at test time. There are definitely use cases where that's acceptable.
I'm very certain you can statically analyze zig's IR for safety without language change. And zig makes it easier to get consistency than C because you are steered away from the mishmash of malloc/jemalloc/pick-your-allocator-function. (The analyzer can say "all bets are off if you don't use the allocator interface") same with the new stdlib io interface for async-shaped analysis on aliasing analysis
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.
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 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.
Zig's tooling is very good, so is the cross-compatibility story and tagged unions.
But while you can have some/most of the benefits Zig has from modern C, I think an underrated benefit is the language culture. As a different language it was the opportunity for a reset, e.g. it's idiomatic Zig to pass allocators to functions, meaning every library in Zig will work this way.
You could do that in C, but none or very few libraries do that so whenever you reach out to third-party dependencies (which is not a lot, in C as in Zig) you have to fight against C's traditional patterns.
Because some of those tools exist since 1979, and it keeps being a quixotic battle to make corporations adopt them as standard, until cybersecurity legislation started to take off.
I think this is indeed the main problem. But it would also be the proper solution. For some the "in C/C++ this can not be fixed" narrative is a convenient excuse not to improve their code. Those parties will also not rewrite in Rust, because even with AI this more effort than zero, and zero effort is what they aim for. (and some of those parties are represented in standardization committees and vote against stricter requirements)
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.
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.
A toy example is meant to demonstrate a principle. Toy examples often have alternative ways they can be written, but the concept they are meant to demonstrate requires the whole machinery being employed. Furthermore, how do you think .sum is implemented?
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.
C is in some ways minimal, but the pointer-syntax and some more I absolutely dislike. I also found C++ easier to use in some areas, such as:
cout << "Hey there" << endl;
The equivalent C is simply uglier. Of course C++ failed in other areas big time, but for such simple things like above, I think C++ is better than C. Naturally that cout example is very simplistic, but one can find other examples where C is really quite ugly.
It's not very readable. The logic is forced to always use often useless counters and check them, even on the syntax level. I will take any for each mechanism over the loop style. Map, reduce, fold, all better than having to write counters and the check for it.
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.
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.
Agreed. I'd not ditch the STL completely, but only use its freestanding subset. Implementations contain some very fast SIMD-accelerated code[1]. +The STL works without exceptions.
I don't write much C or C++, but I like writing transpilers and got pretty far with an F# to C backend a while ago, and it was pretty difficult for me (granted it was my first codegen project)
I tried it again with C++ out of curiosity and C++ is ridiculously featured for making it into your own and little domain languages or something that feels like a new feature. Genuinely kind of awesome for transpilers and it definitely gave some insight to the "C++ is awesome, but you have to pick the 20% of features you like" wisdom I've heard
LLMs were fun for exploring C++ patterns as well. I could ask it techniques for approximating some construct in another language and get a full page of toys to try out. It definitely made me want to explore templates in my own language in addition to runtime generics
This is why we need natural language -> pseudo code -> GC typed -> Low level systems.
Both Zig and Rust are fine as the last stage of this software development pipeline with different trade-offs. Problems arise when people try to use them earlier in the process.
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.
> Zig is particularly irrelevant compared to Rust in the LLM era.
This. If we continue on this LLM/AI trajectory, and you're not constrained by your platform to use a specific language, why would you choose C or Zig or C++ over Rust?
You won't be reading or writing the code yourself, LLMs will, and they benefit from a strong type system that catches a lot of issues, meaning fewer tests are needed.
In the general case, there can be cases where it's simply straight up undecidable. (Think of a while loop going for as long as it finds a counterexample to insert your unsolved math problem of your choice) and call a free after. Sure, it's a very contrived example but similar "basically impenetrable barriers" do happen.
But the more common case is simply that each line of code gets some limited "thinking", whether it's inside the model's weights, a thinking block, or a whole turn. Only repeated turns can reason for arbitrary depths, so it's just not necessarily a good use of any of these buckets to spend on something we have a good and efficient algorithm for. Plus any of the former are stochastic which may accidentally ignore true issues (just like humans).
Because LLMs are statistical. They can, with a given probability, avoid memory issues, but cannot prove the non-existance of memory issues in the way that that borrow checkers and other formal methods can.
But... but... they said about so powerful AGI/ASI, and turns out it needs "inertia"/support data and cannot improvise via any isoteric language or write directly machine code.
Yeah, I think AI-generated assembly/machine code will be more and more common. The human-oriented programming language popularity ranks will be pretty much "fixed" from 2025 onwards.
That's overly confident. When I see Rust code, I'm immediately reminded of Scala and how it was supposed to take over the JVM world, but did not, and Kotlin, a much simpler language, is getting more and more popular. You might claim that LLMs have no problem with that kind of language complexity, but people still need to review stuff. I have no doubt that Rust will reach C++ level of popularity, but that still leaves a lot of space for other low-level languages.
Scala "failed" for two reasons: Firstly, (like Haskell) it quickly exceeded its weirdness budget, and cultivated a community that embraced and sustained that weirdness. Secondly, a number of prominent individuals publicly expressed political views that made it hard for engineers in "mainstream" organisations to loudly promote Scala.
I think Rust is doing much better on both fronts. It has always been a more pragmatic language than Scala, and the way it is developed supports that, rather than pushing the weirdness budget higher. The overall political lean of the Rust community is also more amenable to support in mainstream institutions + companies.
"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.
I've been toying with the idea of learning zig and weirdly enough I was looking at this guys book. I don't have any experience with low level languages. The closest I've gotten is Go.
I was debating between C and Zig, but I still don't really know what I want to choose. Feels like C is probably the right choice given the languages age and it could technically be more useful (not that I'd be looking for a job doing C work).
It depends for what you want it. If you're going to do an API, well, Golang is more practical here in my opinion. For TUI apps, I would dare to say Rust was more pleasant than Golang. My experience with Zig was limited, I would not say is not a good fit.
C is still supreme for working on the majority for a Linux/BSD system stack. It also imparts skill that transcend to most other spaces where you may eventually need an FFI to interact with a library anyway or understand how it actually runs on a system.
I would say from a pedagogical perspective, learning C is hugely useful for understanding how programming works at a much lower level.
This has the benefit of you learning about manual memory management and how to deal with all the issues that come with such a rules free language like C that will basically let you do anything. This understanding means lot of the constraints and features that safer languages like Zig and Rust add start to make a lot more sense. For example, going from Python to Rust, the borrow checker will probably seem rather arbitrary, but going from C to Rust, you will find the borrow checker is just automating a lot of checks you were already doing yourself.
For that matter, assembly is useful as well. Not that you have to become an expert in it, but do enough that you understand it from a practical standpoint. It doesn't even have to be on x86, use an emulator of something simple like a 6809 or 6502. I never had trouble understanding pointers in C once I had some experience writing assembly code.
I think you should know C if you want to do low level stuff. It will help understand why zig (or rust) is built the way it is and what is useful about it, too.
struct user *user_new(const char *name, size_t n_groups)
{
struct user *u = malloc(sizeof *u);
if (u == NULL)
goto fail;
u->name = strdup(name);
if (u->name == NULL)
goto fail_user;
u->groups = calloc(n_groups, sizeof *u->groups);
if (u->groups == NULL)
goto fail_name;
return u;
fail_name:
free(u->name);
fail_user:
free(u);
fail:
return NULL;
}
I think you can represent C better than this. I like to focus on one cleanup block, and exploit the fact that free(NULL) is a no-op.
struct user *user_new(const char *name, size_t n_groups)
{
struct user *u = calloc(sizeof *u, 1);
if (u == NULL)
goto fail;
u->name = strdup(name);
if (u->name == NULL)
goto fail;
u->groups = calloc(n_groups, sizeof *u->groups);
if (u->groups == NULL)
goto fail;
return u;
fail:
if (u)
{
free(u->name);
free(u->groups);
}
free(u);
return NULL;
}
Although note that this assumes calloc(sizeof *u, 1) initializes pointers to NULL, IIRC assuming the bit pattern of NULL is all zeroes is technically against the standard but every system you're likely to target will still work.
If you follow the pattern of "it's OK to free NULL pointers", you can also re-use a free function:
struct user *user_new(const char *name, size_t n_groups)
{
struct user *u = calloc(sizeof *u, 1);
if (u == NULL)
goto fail;
u->name = strdup(name);
if (u->name == NULL)
goto fail;
u->groups = calloc(n_groups, sizeof *u->groups);
if (u->groups == NULL)
goto fail;
return u;
fail:
user_free(u);
return NULL;
}
void user_free(struct user *u)
{
if (u)
{
free(u->name);
free(u->groups);
}
free(u);
}
Then user_free() can also be a user-facing API function for cleanup, used elsewhere, and it can be written to be cool with tearing down partially initialized structures.
Regarding the threads I'm seeing in the comments here: it's so frustrating that we have languages like Zig and Nim, among others, which are built for beauty and intuition, but then we have the naysayers that just say "everything that's not Rust or Go is dead because of LLMs, it's over, shut it down and go home".
The ability to vomit out half-baked fragile code at record speeds via plagiarism factories of unprecedented scale with little mental overhead has swung the pendulum so hard in the opposite direction of intellectualism and the human mind. This is why people are depressed about AI. It's a revolution toward soullessness.
llm_nerd | 9 hours ago
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.
dnautics | 8 hours ago
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?
llm_nerd | 8 hours ago
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.
nvme0n1p1 | 8 hours ago
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.
simonask | 8 hours ago
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.
dnautics | 8 hours ago
llm_nerd | 7 hours ago
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.
nvme0n1p1 | 8 hours ago
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)
diffxx | 8 hours ago
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.
nvme0n1p1 | 7 hours ago
Alright then go for it, hotshot. We're waiting.
alexrp | 5 hours ago
Always happy to learn.
acedTrex | 8 hours ago
forgotpwd16 | 7 hours ago
MonstraG | 8 hours ago
https://codeberg.org/ziglang/zig/issues/37402
senderista | 6 hours ago
stateoff | 8 hours ago
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?
dleslie | 8 hours ago
nvme0n1p1 | 8 hours ago
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.
stateoff | 8 hours ago
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 :)
Joker_vD | 8 hours ago
[0] https://news.ycombinator.com/item?id=26296339
dleslie | 8 hours ago
Joker_vD | 6 hours ago
dleslie | 11 minutes ago
Zak | 7 hours ago
drdexebtjl | 8 hours ago
senderista | 6 hours ago
lukaslalinsky | 8 hours ago
brabel | 6 hours ago
chandlore | 7 hours ago
> 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_...
senderista | 6 hours ago
nvme0n1p1 | 8 hours ago
ibn_khaldun | 8 hours ago
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.
raincole | 7 hours ago
I'm not ideologically against AI, but I'd certainly not buy a book from someone who needs to use AI to write an article like that...
[0]: https://www.mtsoukalos.eu/2026/04/why-zig-over-rust-for-syst...
hn_submit | 6 hours ago
eatonphil | 7 hours ago
https://www.pangram.com/history/5f3d749c-713c-447a-82cc-d3a6...
ivanjermakov | 7 hours ago
ibn_khaldun | 7 hours ago
Meanwhile no one's pointing out any technical errors.
schaefer | 5 hours ago
raverbashing | 8 hours ago
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)
brabel | 7 hours ago
jandrese | 5 hours ago
uecker | 7 hours ago
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
pron | 8 hours ago
coolThingsFirst | 8 hours ago
nvme0n1p1 | 8 hours ago
u8080 | 7 hours ago
pron | 7 hours ago
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).
Ygg2 | 7 hours ago
pron | 7 hours ago
clhodapp | 6 hours ago
cornstalks | 6 hours ago
ogogmad | 6 hours ago
cornstalks | 5 hours ago
Ygg2 | 4 hours ago
Which seems to be something Zig can't do.
Hell, you can define operators for generic length SIMD lane.
pron | 50 minutes ago
Ygg2 | 5 hours ago
Can I write my SIMD/number abstraction and have it work?
Let's say I need rotors. With six dimensions. Can I overload it's basic numeric operations?
bunderbunder | 6 hours ago
A more humble critique would be to just acknowledge that you don’t seem to be a member of Zig’s target audience, and move on.
Ygg2 | 4 hours ago
Saying "you don't want operator overloading" in such cases is a reductionist view of how systems programming should look.
hitekker | 3 hours ago
Ygg2 | an hour ago
bunderbunder | an hour ago
The point is, it’s a tradeoff. With overloading, exactly which code executes on a specific line becomes a bit more implicit because it depends on extra information from the surrounding context: the types of the arguments.
That comes with the usual tradeoffs. On the one hand, you could argue that the compiler is taking care of it for you, which saves the programmer from having to manually deal with it, and removes some visual clutter from the code.
But you can also argue that letting the choice of function be implicit means that a programmer who wants/needs to keep track of exactly what every line of code is doing needs to carry all that contextual information in their own head, too. For this programmer, it’s adding to the mental burden.
I don’t think it’s a coincidence that Kelley constantly brings up how Zig was inspired by difficulties writing a digital audio workstation with very hard real-time requirements. Part of what he’s doing there is giving a motivating case for why he wants to be an absolute control freak about, e.g., micro-managing exactly when memory is allocated and deallocated. That’s something only a subset of systems programmers need, because not all systems programming is dealing with things like hard real-time.
Ygg2 | 49 minutes ago
>But you can also argue that letting the choice of function be implicit means that a programmer who wants/needs to keep track of exactly what every line of code is doing
Use LSP/IDE then ctrl+click operator. Boom. You see what it's executing.
Idea is to create abstraction that make it easier to operate on a more complex level. If you need that level of micro-managing just stick to assembly.
tialaramex | 6 hours ago
I actually don't like Rust's choice to implement + for Strings but most people seem to accept that, however C++ goes ludicrously far beyond "I don't like it but some people do" and straight off the cliff into "Nobody thinks that's OK" leaving you to wonder why there was effort to implement this bad idea. For example C++ can overload the short-circuiting boolean operators... but the overloaded versions don't short circuit. So now you've made things dramatically worse!
pron | 5 hours ago
tialaramex | 3 hours ago
This depends on how you're squinting at this word "resolution".
Remember on a modern CPU an XOR R1 R1 does not result in an ALU operation, the decoder understands this idiom and just renames a zero'd register as R1, whereas of course it can't do that for say XOR R2 R3 because that's an actual XOR operation. So if "resolution" means "exactly what happens on the CPU" apparently there is no such facility provided even in assembler.
So apparently we mean only that it should have, in some sense, the same effect. I think the fact Rust is OK with
.. meets this criterion, whereas presumably you do not agree.pron | 3 hours ago
melodyogonna | 7 hours ago
vnorilo | 6 hours ago
bunderbunder | 6 hours ago
For a somewhat different example of the same general idea, look at how Java handles primitives and their boxed counterparts. = on two ints always compares their value. = on two Integers compares their pointers. But it uses flyweight instances for values up to 256, so in Java, whether two Integers with the same numeric value are equal according to the = operator depends on what that value is.
Then throw autoboxing and generics into the mix, and it suddenly becomes very easy to do refactorings that work fine in the unit tests (which tend to use small numbers) but fails in confusing ways in production.
This isn’t an example of operator overloading, of course. But I hope it more simply illustrates why, at least in certain problem domains, there’s value in being able to visually tell when surprising runtime shenanigans are and are not possible. And also to make it impossible to cross that boundary without touching all code that falls within the blast radius of that change.
wpollock | 5 hours ago
I believe Java caches Integer objects for values -128..+128, not 256. But that may be an implementation detail, and not something to count on.
gf000 | 5 hours ago
wpollock | 3 hours ago
I'm looking forward to structured concurrency in Java 28. I already thought of a title for my article "Java Concurrency - Past, Present, and Futures".
bunderbunder | 5 hours ago
wpollock | 4 hours ago
We both misremembered. I found where this is documented and the range is -128..127 inclusive: <https://docs.oracle.com/en/java/javase/27/docs/api/java.base...>
ogogmad | 7 hours ago
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.
positive-spite | 8 hours ago
Rust just stabilized its `Allocator` API in version 1.100.0. Definitely worth checking out!
Bigpet | 7 hours ago
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.
treyd | 7 hours ago
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.
Bigpet | 7 hours ago
> 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.
tialaramex | 6 hours ago
If you want to use your MyCustomAllocator with a HashMap or a BinaryHeap or you've lost your mind and want a LinkedList none of that was stabilized yet.
Personally I am slightly interested in HashMap, VecDeque and String but I think Vec is much more heavily used than any of those and will illustrate just how thin the pickings are in this space for real.
atiedebee | 4 hours ago
tialaramex | an hour ago
If there's a particular 3rd party collection you know would benefit, you could ask them, or write a PR to make use of Allocator. The standard library collections of course know people are interested, you can think of this as an MVP.
I just picked a few I personally want to see.
tialaramex | 6 hours ago
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.
Bigpet | 3 hours ago
I have no practical Odin experience, I just looked at the core concepts. I tried a bit of Zig and there's significant discipline in the standard library to enable allocator use. But in 3rd Party libraries this discipline is hard to enforce because it also makes it harder to design easy to use interfaces.
I'm interested where on the spectrum of allocator usability Rust will end up at. I'd expect it somewhere between Zig and C++
program | 8 hours ago
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).
uecker | 6 hours ago
mogoh | 8 hours ago
ginko | 8 hours ago
mi_lk | 7 hours ago
dralley | 6 hours ago
ACCount39 | 7 hours ago
kombine | 7 hours ago
tcoff91 | 7 hours ago
giancarlostoro | 7 hours ago
vips7L | 7 hours ago
giancarlostoro | 7 hours ago
https://github.com/buggins/dlangide
vips7L | 5 hours ago
giancarlostoro | 7 hours ago
sergiotapia | 7 hours ago
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
Fervicus | 4 hours ago
seanw444 | 4 hours ago
I don't mean that as an insult to Zig. Zig is amazing. But the ergonomics of Nim are just unbeatable.
bowsamic | 7 hours ago
arc619 | 5 hours ago
bowsamic | 5 hours ago
bmandale | 4 hours ago
fithisux | 7 hours ago
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.
uecker | 7 hours ago
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.)
bunderbunder | 7 hours ago
https://blog.codinghorror.com/falling-into-the-pit-of-succes...
uecker | 6 hours ago
ProphetOfParado | 6 hours ago
These days I wonder what is harder: 1. problems of collective action or 2. communicating that reducing everything to collective action is the real issue.
yawpitch | 6 hours ago
markatto | 4 hours ago
bioneuralnet | 4 hours ago
uecker | 4 hours ago
bunderbunder | 3 hours ago
Suppose, also, that they have decided to make the change incrementally. So a rewrite is not in the cards.
The advantage of sticking with C that I see is that nobody has to learn a new language, migrate to a new toolchain, anything like that. So it is definitely the smaller change. But the downside is that it may be more difficult to hold the line. For some indeterminate (possibly indefinite) period of time you have a mix of legacy code that's being allowed to stay on the old conventions, and new/migrated code that's supposed to be held to the new conventions. IME one solo developer can maintain that distinction, but a team working in a business environment, possibly with people cycling on and off, will struggle with it. You can try to bake the distinction into your tooling, but that's often easier said than done. Most tools expect one set of conventions per project.
The advantage of adopting Zig that I see is that you set a clear demarcation line. New files will be written in Zig. Migrated code gets ported to Zig. Everyone knows that Zig has one coding standard, C has another coding standard. They look different, so it's easy to keep track of which is which. They each have their own compiler flags and static analysis tools, so it's hopefully easier to separate the legacy rules from the new ones.
Now, I mostly do cruddy business applications so I haven't actually done this with C and Zig. But I have done it on the JVM, and IME whether "modernize legacy Java in place" or "modernize legacy Java by strangler vining over to Kotlin" works better depends heavily on what the legacy code in question actually looks like and how much you want to change.
uecker | an hour ago
slopinthebag | 5 hours ago
sergio-gdr | 7 hours ago
William_BB | 7 hours ago
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.
0c3ca83 | 6 hours ago
logicchains | 6 hours ago
0c3ca83 | 6 hours ago
metaltyphoon | 6 hours ago
woodruffw | 6 hours ago
William_BB | 6 hours ago
0c3ca83 | an hour ago
William_BB | 6 hours ago
0c3ca83 | 2 hours ago
dnautics | 6 hours ago
github.com/ityonemo/clr
erikpukinskis | 6 hours ago
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.
bunderbunder | 6 hours ago
uecker | 6 hours ago
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.
metaltyphoon | 6 hours ago
This is why new ecosystems starts. Not everyone is ok with the slow pace
uecker | 4 hours ago
But I think a fair comparison of new languages to C has to take modern C features and tooling into account.
simjnd | 6 hours ago
But while you can have some/most of the benefits Zig has from modern C, I think an underrated benefit is the language culture. As a different language it was the opportunity for a reset, e.g. it's idiomatic Zig to pass allocators to functions, meaning every library in Zig will work this way.
You could do that in C, but none or very few libraries do that so whenever you reach out to third-party dependencies (which is not a lot, in C as in Zig) you have to fight against C's traditional patterns.
znpy | 6 hours ago
1. yeah you can do that, but we should really do some (most? all?) of the things you mention (as well as other safeguards) mandatory
2. your code might be alright, but what about your dependencies ?
skohan | 6 hours ago
pjmlp | 5 hours ago
uecker | 4 hours ago
drnick1 | 7 hours ago
nine_k | 7 hours ago
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.
tempest_ | 6 hours ago
raincole | 7 hours ago
bmandale | 4 hours ago
forgotpwd16 | 7 hours ago
zzzoom | 5 hours ago
bmandale | 4 hours ago
it is, in fact, better
shevy-java | 5 hours ago
C is in some ways minimal, but the pointer-syntax and some more I absolutely dislike. I also found C++ easier to use in some areas, such as:
The equivalent C is simply uglier. Of course C++ failed in other areas big time, but for such simple things like above, I think C++ is better than C. Naturally that cout example is very simplistic, but one can find other examples where C is really quite ugly.zelphirkalt | 2 hours ago
pipeline_peak | 7 hours ago
jftuga | 7 hours ago
Numerlor | 7 hours ago
And of course it needs to get to stable first
variadix | 7 hours ago
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.
jandrewrogers | 6 hours ago
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.
jimbob45 | 6 hours ago
faresahmed | 6 hours ago
[1]: https://github.com/microsoft/STL/blob/main/stl/src/vector_al...
pjmlp | 5 hours ago
bbkane | 5 hours ago
pjmlp | 4 hours ago
lilbigdoot | 4 hours ago
lilbigdoot | 4 hours ago
I tried it again with C++ out of curiosity and C++ is ridiculously featured for making it into your own and little domain languages or something that feels like a new feature. Genuinely kind of awesome for transpilers and it definitely gave some insight to the "C++ is awesome, but you have to pick the 20% of features you like" wisdom I've heard
LLMs were fun for exploring C++ patterns as well. I could ask it techniques for approximating some construct in another language and get a full page of toys to try out. It definitely made me want to explore templates in my own language in addition to runtime generics
adsharma | 4 hours ago
Sometimes I want to think about algorithms and memory management separately.
Try translating to zig.This is why we need natural language -> pseudo code -> GC typed -> Low level systems.
Both Zig and Rust are fine as the last stage of this software development pipeline with different trade-offs. Problems arise when people try to use them earlier in the process.
qweqwe14 | 7 hours ago
lossolo | 5 hours ago
This. If we continue on this LLM/AI trajectory, and you're not constrained by your platform to use a specific language, why would you choose C or Zig or C++ over Rust? You won't be reading or writing the code yourself, LLMs will, and they benefit from a strong type system that catches a lot of issues, meaning fewer tests are needed.
nickmonad | 5 hours ago
gf000 | 5 hours ago
But the more common case is simply that each line of code gets some limited "thinking", whether it's inside the model's weights, a thinking block, or a whole turn. Only repeated turns can reason for arbitrary depths, so it's just not necessarily a good use of any of these buckets to spend on something we have a good and efficient algorithm for. Plus any of the former are stochastic which may accidentally ignore true issues (just like humans).
14113 | 3 hours ago
mglvsky | 5 hours ago
raincole | 5 hours ago
mglvsky | 4 hours ago
Poor AI
/s
raincole | 4 hours ago
No /s
Fervicus | 5 hours ago
We did?
anttiharju | 4 hours ago
lukaslalinsky | 3 hours ago
14113 | 3 hours ago
I think Rust is doing much better on both fronts. It has always been a more pragmatic language than Scala, and the way it is developed supports that, rather than pushing the weirdness budget higher. The overall political lean of the Rust community is also more amenable to support in mainstream institutions + companies.
shevy-java | 7 hours ago
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.)
brabel | 6 hours ago
eliasdejong | 6 hours ago
dava96 | 6 hours ago
I was debating between C and Zig, but I still don't really know what I want to choose. Feels like C is probably the right choice given the languages age and it could technically be more useful (not that I'd be looking for a job doing C work).
For those that know both, what would you pick?
meerita | 6 hours ago
kev009 | 6 hours ago
mmilunic | 6 hours ago
This has the benefit of you learning about manual memory management and how to deal with all the issues that come with such a rules free language like C that will basically let you do anything. This understanding means lot of the constraints and features that safer languages like Zig and Rust add start to make a lot more sense. For example, going from Python to Rust, the borrow checker will probably seem rather arbitrary, but going from C to Rust, you will find the borrow checker is just automating a lot of checks you were already doing yourself.
TLDR: Learn C. I would recommend the 15122 CMU course as a pretty good foundation. You can find it online here https://www.cs.cmu.edu/~15122/schedule.shtml .
SoftTalker | 5 hours ago
pastel8739 | 6 hours ago
asveikau | 5 hours ago
If you follow the pattern of "it's OK to free NULL pointers", you can also re-use a free function:
Then user_free() can also be a user-facing API function for cleanup, used elsewhere, and it can be written to be cool with tearing down partially initialized structures.dgan | 4 hours ago
Kevin_Flynn | 4 hours ago
I'm going to keep using C.
Its in my AGENTS.md file.
seanw444 | 4 hours ago
The ability to vomit out half-baked fragile code at record speeds via plagiarism factories of unprecedented scale with little mental overhead has swung the pendulum so hard in the opposite direction of intellectualism and the human mind. This is why people are depressed about AI. It's a revolution toward soullessness.