HN user
This isn't a very exciting release: it adds a few useful things to libraries and to generic compile time introspection – but that's pretty much it.
Just some incremental improvements.
If you haven't tried C3, feel free to jump to https://learn-c3.org and try it in the browser.
Yep
Counterpoint: https://news.ycombinator.com/item?id=47989154
One funny thing is that if you go on codeberg and want to submit a PR to Zig, you can't. Because Zig's too big for Codeberg, and you're over your free quota, so you can't push your update to your fork.
Yes there are ways around it if you have patience, but what the heck!!
Early days of Wikipedia was the wild west. Surely you must agree to that.
No, Grokipedia is just a crapfest. I'm talking about actually asking ChatGPT
And as an example of bias: I personally witnessed a wikipedia editors adding their own interpretation of a certain written article. This interpretation was very politically biased and not justified by the text, but these were influential wikipedia editors so that it stayed in. I then asked the author of the article on Twitter if this interpretation was correct. I was unambiguously told NO. This information (including the public twitter conversation), was rejected by the wikipedia editors because it was first hand accounts.
Which led to the rather odd result that the interpretation of an article's message by a Wikipedia editor was favoured over the explicit statement by the article's author.
Here I would have thought that it would have been prudent to simply leave out that part of speculation, but they adamantly insisted it should stay.
I must add that this happened on Swedish wikipedia, not the main English Wikipedia – which I actually found much more balanced. But the problem is that this mechanism exists in the first place.
It was at the time (5-10 years ago?) well known that the Wikipedia of some language – I don't recall which one – was at the time pretty much hijacked by a group. Oh, wait I found it - the Croatian Wikipedia.
This is unlikely to happen to the main Wikipedia, but it does demonstrate a certain brittleness and risk of bias in the system.
The C3 grokipedia entry was horribly bad, so I don't really have a favourable impression of it.
It's funny. Today people say that of Wikipedia, as if it was trustworthy. But it used to be common knowledge to just "don't trust anything on Wikipedia". Wikipedia was never like a regular encyclopedia, it just wanted to be one.
Its biggest advantage over traditional encyclopedias was its breadth and how quickly it could be updated. The trade-off was that articles could vary greatly in quality and could be edited by anyone, making accuracy less consistent than in traditionally edited reference works. So the effort to reduce breadth and say it shouldn't be updated quick... that's just strikes me (as someone fairly old) as kind of funny.
What kind of happens is that there are some people who invest their lives in Wikipedia, their opinions is what ends up mattering.
This has boths pros and cons. The good thing about it, is that these people are deeply invested in Wikipedia and therefore have a lot of incitament to do what (they believe at least) is the best for Wikipedia.
The downsides are: (1) that just because you invested a lot of time into Wikipedia you don't have biases (2) you are not immediately qualified to determine whether some article/source is bad or not from a factual point of view.
Also, it's very HARD to become a regular contributor, because you'll have to invest an insane amount of time initially to build up goodwill and reputation, when at the same time anything you do might just get reverted because someone thought it was too much detail or bad in some other way.
So it's a very punishing environment which makes sure that the actual group of Wikipedia editors is a fraction of what one could expect. (Also, the Wikipedia markup... it's really the worst dialect of Wiki syntax)
Anyway, all of this is probably not good for Wikipedia in the long run. LLM's will be much better than humans at creating "beginner" articles, and it will be increasingly hard to know what's LLM-authored. So I expect Wikipedia to go the way of Stack Overflow in the long run.
The Zig C import is going away, moving into a tool invoked from build.zig, so this might not be an ideal thing to point to.
C3 just has everything C compatible so not just calling into C but also C calling to C3 is just completely normal with no special compatibility types/functions, unlike Zig.
So which one has the most compelling feature kind of boils down to what one focuses on.
You can find Odin users that praise Odin for finding their sweet spot. Similarly for C3 users, just like Zig users.
And in each of those, they will say that the others didn’t quite match what they wanted (not in all cases though: the relatively high visibility of Zig means a lot of its users is unaware of the languages with less visibility, and just pick it by default)
If you use LLVM at least, they expand to a lot of code which is repeated on every operation. There’s a point where the inline code will just blow the instruction cache and just create unacceptable binary bloat.
$400k is serious money and will certainly help keeping the Zig team funded. I must gratulate Andrew and the team on their ability to create a product that is creating this kind of enthusiasm from its users.
One thing that’s sometimes overlooked though is that all donations are something that we’re grateful for, regardless of amount. If you have little to spend then even $1 a month is an investment that rivals $10000 by someone rich.
Also worth remembering is that the vast majority of language projects aren’t operating at Zig’s scale. For smaller projects such as C3, even modest recurring support can have a meaningful impact on long-term sustainability.
It doesn’t need to be $100000s a month to make a huge difference.
Zig syntax has been mostly stable since 0.2, it is extremely unlikely it will change beyond tweaks. You have to go to Odin, C3 or (in the future) Jai for an alternative.
As a contrast to Zig: C3 is strongly invested in contracts and is able to use them for static analysis at compile time to some degree.
The difference is that in the unsigned case you get a seemingly plausible value, and in the signed case you get a negative value which you can be sure is wrong. This is the problem.
Odin started in 2017, had a fraction of the contributors and is soon 1.0, so that explanation isn’t cutting it.
If you instead look at the over 500 kloc of the Zig source compared to the 70 kloc of the Odin one, it’s a bit clearer why the delay happened: the goals of Zig kept expanding.
But not only that: ”juicy main” and Io is something that could have been in Zig from the early days and yet it isn’t. In the Io case it’s Zig pivoting from ”we have colorless async!” to no async, to Io.
In other words, Andrew is still experimenting with the language (and more is to come, like ranged integers). This is not the signs of a maturing language, it a language still very much in flux, trying to find its form.
The contrast to Odin is that for the last 2-3 years it has had minimal syntax tweaks, and is essentially in release candidate mode for the language.
Even if Zig didn’t need more changes, it would still need that stabilization period.
This tells us Zig is still rather far from 1.0.
I wonder what Andrew is thinking about all this.
I think Andrew should seriously think about decoupling the toolchain from the language to put focus on reaching stability there. As it is, we have the compiler with surrounding toolchain, the standard library and the language. The two former can keep evolving even language is fixed.
Just being ambitious isn’t necessarily good. Look at Perl6.
C3 0.7.11 is the final release in the 0.7 series.
This version focuses on tightening semantics, improving type inference, and cleaning up edge cases rather than adding new features. Some parts of the standard library (like matrices) have also been reworked.
The goal is to stabilize behavior and reduce inconsistencies before starting the 0.8 cycle.
C3 is aiming to stay close to C in terms of control and predictability, while reducing complexity in everyday use.
I just have to add another reflection:
One thing that tends to be overlooked when discussing changes is the ecosystem effect of frequent changes.
A language that breaks frequently doesn't just impose upgrade work on apps, but also discourages the creation of long-lived libraries and tools. Anything that sits between the language and the user (linters, bindings, frameworks, teaching material, tutorials etc) has to to some degree "chase the language"
This means that the ecosystem will skew toward very actively maintained libraries and away from "write once then leave it alone" libs. And this the trade-off is reasonable during early language design, but it's worth acknowledging that it has real consequences for ecosystem growth.
One should note that other newer languages have put significant effort into minimizing this churn, precisely to allow the latter type of ecosystem to also form. So it's kind of an experiment, and it will be interesting to see which approach ends up producing the larger ecosystem over time.
Not at all, if the team needs 30 more years they should take it.
Yes, I understand that is the opinion in the Zig community. As an outsider, it seems odd to me to pick a language that I constantly need to maintain.
> However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0.
Funny you see it as bleak when most of the community sees it as the most excitinh thing in systems programming happening right now.
You misread that one. I was talking about the odds of seeing a 1.0 version of Zig soon.
I think you comment is in bad faith, all the big zig projects say that the upgrade path is never a main concern, just read HN comments here or on other zig threads, people ask about this a lot and maintains always answer.
Maybe you didn't read what I wrote carefully enough. This is part of the protectiveness from the Zig community that prompted me to write in the first place.
WITHIN the Zig community it is deemed acceptable for Zig upgrades to break code. Consequently it becomes simple survivor bias that people who use Zig for larger projects don't think that this is a major concern BECAUSE IF THEY FELT IT WAS A CONCERN THEY WOULD NOT USE ZIG.
Whether programmers at large feel that this is a problem is an unknown still, since Zig has not yet reached to point of general adoption (when people use Zig because they have to, rather than because they want to).
However, it is INCORRECT to state that just because a language is not yet 1.0 it needs to break older code aggressively without deprecation paths. As an example, Odin removed the old `os` module and replaced it with the new "os2". This break was announced half a year in advance and lots of thought was put into reducing work for developers: https://odin-lang.org/news/moving-towards-a-new-core-os/
In the case of C3, breaking changes only happen once a year with stdlib going through the general process of deprecating functions long before removing them.
I wanted to highlight how these are quite different approaches. For established languages, this is of course even more rigorous, but neither C3 nor Odin are 1.0, and still see this as valuable and their communities then end up expecting it.
So please understand that when you say "it's never a main[sic] concern", this is simple survivor bias.
I am using games, because they pop up more often (gamejams etc), but we can see the same if we'd look at utility apps. Do you want to broaden that to "Odin is more explicitly marked towards writing applications", but if so what would that say of Zig?
However we value explicitness and allow the developer to do anything they need to do*
* except for having unused variables. Those are so dangerous the compiler will refuse the code every time.
It’s good to see that this is finally addressed. It’s been a well known broken part of the language semantics for years.
There are similar hidden quirks in the language that will need to be addressed at some point, such as integer promotion semantics.
To address the question about stability: the Zig community are already used to Zig breaking between 0.x versions. Unlike competitors such as Odin or my own C3, there is no expectation that Zig is trying to minimize upgrading problems.
This is a cultural thing, it would be no real problem to be clear about deprecations, but in the Zig community it’s simply not valued. In fact it’s a source of pride to be able to adapt as fast as possible to the new changes.
I like to talk about expectation management, and this is a great example of it.
In discussions, it is often falsely argued that ”Zig is not 1.0 so breaks are expected” in order to motivate the frequent breaks. However, there are degrees to how you handle breaks, and Zig is clearly in the ”we don’t care to reduce the work”-camp.
If someone is trying to get a more objective look at the Zig upgrade path, then it’s worth keeping in mind that the tradition in Zig is to offload all the work on the user.
The argument, which is frequently voiced, is that ”breaking things will make the language get better and so it’s good that there are language breaks”
It is certainly true that breaking changes are needed, but most people outside of the Zig community would expect it to be done with more care (deprecation paths etc)
Secondly, it should perhaps be a concern for Zig, now at 10 years old, to still produce solidly breaking code every half year.
10 years is the common point where languages go 1.0. However, the outlook for a Zig 1.0 is bleak from what I gather from Zig social forums: the most optimistic estimate I’ve heard is 2029 for 1.0.
This means that in the future, projects using Zig can still expect any libraries and applications to bitrot quickly if they are not constantly maintained.
Putting this in contrast with Odin (9 years old) which is essentially 1.0 already and has been stable for several years.
Maybe this also explains the difference in actual output. For example the number of games I know of written in Odin is somewhere between 5 to 10 times as many as Zig games. Now weighing in that Zig has maybe 5 or 10 times as many users, it means Odin users are somewhere between 20-100 times as likely to have written a playable game.
There are several explanations as to why this is: we could discuss whether the availability of SDL, Raylib etc is easier on Odin (then why is Zig less friendly?), maybe more Odin has better programmers (then why do better programmers choose Odin over Zig), maybe it’s just easier to write resource intensive applications with Odin than Zig (then what do we make of Zig’s claim of optimality?)
If we look past the excuses made for Zig (”it’s easy to fix breaks” ”it’s not 1.0”) and the hype (”Zig is much safer than C” ”Zig makes me so productive”) and compare with Odin in actual productivity, stability and compilation speed (neither C3 nor Odin requires 100s of GB of cache to compile in less than a second using LLVM) then Zig is not looking particularly good.
Even things like build.zig, often touted as a great thing, is making it really hard for a Zig beginner (”to build your first Hello World, first understand this build script in non-trivial Zig”). Then for IDEs, suddenly something like just reading the configuration of what is going to be used for building is hidden behind an opaque Zig script. These trade-offs are rarely talked about, as both criticism and hype is usually based on surface rather than depth.
Well, that’s long enough of a comment.
To round it off I’d like to end on a positive note: I find the Zig community nice and welcoming. So if you’re trying Zig out (and better do that, don’t let others’ opinions - including mine - prevent you from trying things out) do so.
If you want to evaluate Zig against competitors, I’d recommend comparing it to D, Odin, Jai and C3.
C3 0.7.10 introduces constdef, syntactically and semantically making a clear distinction between proper enums and "enums is collection of constants".
Other improvements in this release:
- Much improved MSVC cross compilation
- Quality-of-life fixes
- Custom LLVM builds to reduce external dependencies
C3 is a language designed as an evolution of C, without retaining strict backwards compatibility, but excellent interop with C.
This version departs from its rather uncommon module-based generics, but doesn't go all the way to C++ style templates. Instead generics can be grouped for common constraint checking on template parameters and instantiation. As usual it also contains fixes and additions to the stdlib.
Some older posts on C3:
- https://news.ycombinator.com/item?id=46463921
- https://news.ycombinator.com/item?id=43569724
- https://news.ycombinator.com/item?id=24108980
- https://news.ycombinator.com/item?id=27876570
- https://news.ycombinator.com/item?id=32005678
Try out C3 in the browser:
Here are some interviews on C3:
- https://www.youtube.com/watch?v=UC8VDRJqXfc
- https://www.youtube.com/watch?v=9rS8MVZH-vA
Here is a series doing various tasks in C3, slightly dated:
- https://ebn.codeberg.page/programming/c3/c3-file-io/
Repository with link to various C3 resources and projects:
- https://github.com/c3lang/c3-showcase
Some projects:
- Gameboy emulator https://github.com/OdnetninI/Gameboy-Emulator/
- RISCV Bare metal Hello World: https://www.youtube.com/watch?v=0iAJxx6Ok4E
- "Depths of Daemonheim" roguelike https://github.com/TechnicalFowl/7DRL-2025
I didn't see any similarities to C3, quite the opposite.
C2 (http://c2lang.org) similarly compiles to C, but arguably more readable C code from what I can see. The benefits are (1) easy access to pretty much any platform with little extra work (2) significantly less long term work compared to integrating with LLVM or similar (3) if it's readable enough, it might be submitted as "C code" in working environments which mandate C.
It would be interesting to hear the motivation for it.
But it of course move semantics and destructors affect all things. If the goal is to call and be callable from C without special constructs, how would you make the C code respect the move semantics and destructors?