I feel like it's worthless to keep up with Zig until they reach 1.0.
That thing, right here, is probably going to be rewritten 5 times and what not.
If you are actively using Zig (for some reasons?), I guess it's a great news, but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga...
So m'yeah. I was following Zig for a while, but I just don't think I am going to see a 1.0 release in my lifetime.
gethly 2 hours ago [-]
0.16 ... maybe in 2050 they will finally release v1.0.
Jokes aside, once Jai comes out, Zig will become obsolete. Odin might hang on, as it is quite a bit smaller and limited language. Rust is being forced into every low level codebase, so that one will stay. C3, well, no one is using that, like Carbon. But Zig... despite running some big projects, it has no future.
ivanjermakov 4 minutes ago [-]
When in comes to programmming languages, I would rather see a language done right after 20 years of development than what we see today with all mainstream languages splatting features and breaking changes without care for overall language conciesness and usability.
See Python 2->3, Rust async traits, Go generics, C++... basically everything.
BonusPlay 2 hours ago [-]
Instead of debating for years (like other languages), zig just tries things out. Worst case you can always rollback changes.
IMO best APIs and designs are those that are battle tested by end users, not won in an argument war during committee meetings.
This makes zig unique. It's fun to use and it stays fresh.
You can always just stay on older version of zig. But if you choose to update to newer version, you get new tools to make your code tidier/faster.
pjmlp 2 hours ago [-]
Other languages debate for years, because they have a customer base with important applications into production that don't find funny that their code is broken with experiments.
Zig is years away to become industry relevant, if at all, of course they can experiment all they like.
Pay08 2 hours ago [-]
Obviously, that comes with the language being in beta. If you don't want things broken, use a complete language.
zarzavat 1 hours ago [-]
It's hard to imagine Zig ever becoming stable and conservative. Even at 10 years old, it's still as beta as ever. At some point the churn becomes part of the culture.
Not a complaint, just an observation. I like that they are trying new things.
Pay08 1 hours ago [-]
I wouldn't be so sure about that. I do think there's a bit of scope creep, especially with the LLVM replacement stuff, but I don't think it's bad enough for the language to never come out. Most notable languages have at least one large corporate sponsor behind them, Zig doesn't.
the_mitsuhiko 50 minutes ago [-]
I’m a casual user and the 0.16 changes scare me. I tried multiple attempts now, even with full LLM support to upgrade and the result is just a) painful and b) not very good. I have high doubts that the current IO system of 0.16 will make it for another release given the consequences of their choices.
kristoff_it 4 minutes ago [-]
Here's some advice:
1. if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work (because they're still tinkering with them) also you can't expect docs until the design is somewhat finalized (which is not yet, fyi)
2. llms don't help when trying to make sense of the above (a feature that is not complete, that has no docs other than some hints in commit messages, that changes every other commit), reserve llms for when things are stable and well documented, otherwise they will just confuse you further.
If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.
nickorlow 1 hours ago [-]
I think it benefits the overall ecosystem for them to experiment so other languages can take what works
quietbritishjim 1 hours ago [-]
> Instead of debating for years (like other languages), zig just tries things out.
Many other languages do try things out, they just do it in a separate official channel from the stable release or unofficial extensions. Depending on how many users the language has, that may still be more implementation experience than Zig making all devs try it.
I suspect the actual difference is the final decision making process rather than the trial process. In C++, language extensions are tried out first (implementation experience is a requirement for standard acceptance) but committee debates drag on for years. Whereas Python also requires trial periods outside the stable language but decisions are made much more quickly (even now that there's a steering rather than single BDFL).
rurban 37 minutes ago [-]
> Instead of debating for years (like other languages), zig just tries things out.
Good
> Worst case you can always rollback changes.
No, you cannot. People will leave in masses. In perl they announced experiments with a mandatory use experimental :feature. You couldnt publish modules with those, or else you are at risk.
This made perl exciting and fresh. Python on the other hand constantly broke API's, and had to invent package version locks and "safe" venv's. Which became unsafe of course.
Languages and stdlib are not playgrounds. We see what came out of it with C and C++ with horrible mistakes getting standardized.
ozgrakkurt 19 minutes ago [-]
I recently ditched zig because of this.
I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.
Also build system API and some other APIs change and it is super annoying.
Find it much better to use c23 with _BitInt integers and some macros and context passing for error handling.
Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.
It is understandable that breaking APIs is good for development but in most cases new API isn’t that good anyway.
And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”
SkiFire13 17 minutes ago [-]
> IMO best APIs and designs are those that are battle tested by end users
Battle testing an API however requires time and the API to not constantly change.
jiehong 2 hours ago [-]
This is a great point, and it's actually something I really enjoy that the JVM and Java do nowadays by namespacing the new experimental APIs that you test from release to release and then it's stabilized like that, and becomes broadly available.
interstice 2 hours ago [-]
This is my favourite way to iterate, but the hard lesson is at some point after trying a bunch of things comes the Big Cleanup (tm). Is that a potential issue for this with Zig?
BonusPlay 2 hours ago [-]
From my perspective zig doesn't have "big cleanup" upfront. It's removing older features as it goes.
stdlib changes as it wants from version to version. So do language features. Since zig is pre-1.0, zig foundation isn't scared of breaking changes.
SSLy 2 hours ago [-]
0.16's IO API changes might be that cleanup.
Ygg2 2 hours ago [-]
> Instead of debating for years (like other languages), zig just tries things out.
So did Rust pre-1.0
Stability guarantees are a pain in the neck. You can't just break other people's code willy nilly.
> This makes zig unique. It's fun to use and it stays fresh.
You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.
alexrp 28 minutes ago [-]
Just on this point:
> You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.
The idea with making std.Io an interface is that we're not forcing you into using green threads - or OS threads for that matter. You can (and should) bring your own std.Io implementation for embedded targets if you need standard I/O.
WJW 2 hours ago [-]
Kinda weird to blame Zig for not being at 1.0 yet while Jai is still in closed beta after 11 years. Meanwhile Zig is being in used in big-ish projects all over while Jai has... a single game engine? Jai looks cool but it's far far FAR behind and losing ground.
pjmlp 48 minutes ago [-]
The fallacy of that argument would be if its author would seek adoption, however like Naughty Dog with their Lisp based language, John has no plans to have Jai win world adoption beyone his game engine.
WJW 11 minutes ago [-]
That may be, but OP tried to claim that
> once Jai comes out, Zig will become obsolete
If Jai is happy to have limited adoption (which is fine), other languages will by definition not be displaced by Jai. That is even if we accept OPs implied point, that Jai is good enough to displace Zig, without further discussion. But even that seems to be rather doubtful.
pjmlp 2 minutes ago [-]
Agreed, however I also think Zig will be another Coffee Script, PureScript, Elm,...
I advise to revisit HN posts about them.
dmit 1 hours ago [-]
> Jokes aside
Ok ok, good
> once Jai comes out
Dangit! You couldn't even make it to the end of the sentence.
norman784 2 hours ago [-]
I have my doubts on Jai, besides being built towards game development, from what I read/watched about it, it has 2 or 3 meta programming capabilities, like comptime, macros, etc it feels too much of the same, also Jai is not built towards correctness or safety, John mentality is that he knows what he is doing, so he doesn’t need those guardrails and he wants instead expressiveness.
Also Jai is like C++ in complexity, while Zig is similar to C, very simple language.
Carbon is vaporware so far, there’s no language that could be used yet, because they first need to solve the C++ interop and fast compilation times, that is what will shape the language, so no one is using it, because it doesn’t exist yet.
ofalkaed 2 hours ago [-]
>Also Jai is like C++ in complexity, while Zig is similar to C, very simple language.
And most importantly, Zig is aiming at being a C++ replacement with the simplicity of C, it is not trying to replace C.
Pay08 2 hours ago [-]
I think you meant to say Jai, not Zig.
pjmlp 2 hours ago [-]
Good luck with that, it is basically Modula-2 with C like syntax, and we aren't even getting into the whole ecosystem that it is missing on.
Any C++ or C replacement will need to win the earths of mainstream OS and game console vendors, otherwise it will remain yet another wannabe candidate.
Those have already their own languages, alongside their own C and C++ compilers, and are only now starting to warm up to Rust.
Zig or any other candidate will have a very hard time being considered.
ofalkaed 1 hours ago [-]
So no one should even try because they will never win over all of the C/C++ crowd so are doomed to fail and forever to be a wannabe? I think Andrew has gone about things in a good way, going back to C and exploiting hindsight, not trying to offer everything as quickly as possible. Extend C but keep C interoperability and do both better than C++ instead of trying to be the next big thing and he goes about it in a very deliberate and calculated way. He may not succeed, but the effort has given us a great deal.
pjmlp 54 minutes ago [-]
One should try, while being aware of the realities of language adoption.
I disagree Zig is that great deal of a language, it would have been if we were talking about 1990's programming language ecosystem, not in 21st century.
Use-after-free problems should not be something we still need to worry about, when tooling like PurifyPlus trace back to 1992.
ofalkaed 23 minutes ago [-]
I don't think Andrew believes Zig is going kill C or C++, he probably has hope but I think he is aware of the reality. He found a way to make a living on something he was passionate about.
Use-after-free is a fact of life until something kills C, but the realities of language adoption are against that. Zig seems interesting and worthwhile in offering a different perspective on the problem and does it in a way more agreeable than Rust or the like for all those who love C and are adverse to large complex languages. The realities of language adoption are as much for as against Zig, large numbers of people are still getting drawn to C and Zig seems to do a better job addressing why so many are drawn to it than the alternatives.
gethly 2 hours ago [-]
Remember that it was Jai that inspired all these new languages. When you talk about the capabilities like comptime, that's all from Jai and why John no longer does public presentations(as people keep stealing his unfinished ideas).
Your comment about gamedev focus makes no sense as that it the most hardcore segment of all the programming there is. So if a language is good for gamedev, it's good for everything else - with high performance.
I'm still in the GC camp with Go and don't see myself leaving any time soon but Zig is just rust-fugly and takes for ever to complete(it started 10 years ago, mind you). Odin is essentially complete, just lacks official spec. I like it but can' bring myself to use it as it lacks methods and I won' be going back to writing a procedural code like its 2002.
I'm curious to see Jai being released, despite having no use case for it. My initial post is merely about purposefulness, or the lack of, for named programming languages as nowadays John's name will carry more weight than Zig could ever have. so without Zig being 1.0 after a decade, and having no competitive advantage over Jai, it has no chance to survive after Jai is released. As I said, Odin will likely will as it is quite simpler, more niche language. Zig just goes directly against Jai and it will lose.
Matl 54 minutes ago [-]
> Remember that it was Jai that inspired all these new languages.
Not really. Rust was a thing long before Jai.
LunaSea 40 minutes ago [-]
> as nowadays John's name will carry more weight than Zig could ever have.
I'm sorry but Zig has been used to create actual production software for many companies whereas Jai has been used maybe once for a mediocre game.
Phil_Latio 2 hours ago [-]
> why John no longer does public presentations(as people keep stealing his unfinished ideas)
That's your opinion or you have a source for that?
gethly 1 hours ago [-]
he said it in a video, i think it was in the recent wookash podcast. although you might fing a short clip of the segment somewhere.
Fraterkes 36 minutes ago [-]
The idea of languages "stealing" ideas from each other is not something anyone building a language cares about. I'll just charitably assume you've completly misinterpreted something he said.
6r17 2 hours ago [-]
I feel like this is doomerism with high bias - i'm sorry but there is nothing founded here ; for all I know ; if Zig is able to put only one good reason to be used - some people will use it and not care - however this is a purely logical statement and I do not know of Zig so I might be blind here.
small_model 2 hours ago [-]
There are high profile apps written in Zig, Bun (bought by Anthropic) and Ghostty also Uber use it. What apps are written in Jai or Odin.
stock_toaster 1 hours ago [-]
odin - jangafx’s embergen[1]
jai - thekla’s new game, announced but not yet released —- order of the sinking star[2]
Being at 0.16 right now does not mean much. From what I gather, he is more focused on the semantics right now and trying to avoid getting bitten by a lack of foresight down the road, as most every language is. Things will probably start moving more quickly as the language solidifies.
Ygg2 1 hours ago [-]
Any backwards compatible language will accumulate hindsight errors. It's practically inevitable.
cloudhead 2 hours ago [-]
Can you elaborate? Zig has a lot of traction already.
pjmlp 2 hours ago [-]
Except for Tiger Beetle customers and the few ones using Bun, what traction?
Another one to the list, however it hardly sounds like a killer application.
pdpi 6 minutes ago [-]
Ghostty.
steeve 55 minutes ago [-]
ZML
pjmlp 52 minutes ago [-]
What is even that? Not bothering to Google for it, which shows how irrelevant it is.
dmit 49 minutes ago [-]
Good call, for bad reasons.
> At ZML, we are creating exciting AI produ[...]
gethly 1 hours ago [-]
I've read Bun is just a wrapper, not actual Zig implementation anyway. Also, making a financial database in beta language that constantly changes and breaks is "really smart".
dtf 20 minutes ago [-]
You can actually go and read the source yourself [1]. If Bun is "just a wrapper", then surely Node.js and Deno are too?
A wrapper over what?? Bun includes the JavaScriptCore engine for JS evaluation, but it's so much more.
As for financial database concerns, if you're serious about including a project like that in your system, you have thorough correctness and performance testing stages before you commit to it. And once it passes the hurdles, at that point what difference does it make if it's written in a beta language, or a bunch of shell scripts in a trench coat, or whatever.
gigatexal 2 hours ago [-]
Let it come out before we get to chest beating. We are talking about shipped features in Zig here.
2 hours ago [-]
xeonmc 2 hours ago [-]
WalterBright reply in 3...2...1...
jpnc 33 minutes ago [-]
You're right that zig is vaporware - not because of other languages - but because programming is going away entirely.
tosh 2 hours ago [-]
> Both of these are based on userspace stack switching, sometimes called “fibers”, “stackful coroutines”, or “green threads”.
2 hours ago [-]
khalic 43 minutes ago [-]
Haven’t looked into MacOS internals for a while, happy to see they stuck to GCD, great middle ground for parallelisation
Rendered at 11:35:57 GMT+0000 (Coordinated Universal Time) with Vercel.
That thing, right here, is probably going to be rewritten 5 times and what not.
If you are actively using Zig (for some reasons?), I guess it's a great news, but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga...
So m'yeah. I was following Zig for a while, but I just don't think I am going to see a 1.0 release in my lifetime.
Jokes aside, once Jai comes out, Zig will become obsolete. Odin might hang on, as it is quite a bit smaller and limited language. Rust is being forced into every low level codebase, so that one will stay. C3, well, no one is using that, like Carbon. But Zig... despite running some big projects, it has no future.
See Python 2->3, Rust async traits, Go generics, C++... basically everything.
IMO best APIs and designs are those that are battle tested by end users, not won in an argument war during committee meetings.
This makes zig unique. It's fun to use and it stays fresh.
You can always just stay on older version of zig. But if you choose to update to newer version, you get new tools to make your code tidier/faster.
Zig is years away to become industry relevant, if at all, of course they can experiment all they like.
Not a complaint, just an observation. I like that they are trying new things.
1. if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work (because they're still tinkering with them) also you can't expect docs until the design is somewhat finalized (which is not yet, fyi)
2. llms don't help when trying to make sense of the above (a feature that is not complete, that has no docs other than some hints in commit messages, that changes every other commit), reserve llms for when things are stable and well documented, otherwise they will just confuse you further.
If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.
Many other languages do try things out, they just do it in a separate official channel from the stable release or unofficial extensions. Depending on how many users the language has, that may still be more implementation experience than Zig making all devs try it.
I suspect the actual difference is the final decision making process rather than the trial process. In C++, language extensions are tried out first (implementation experience is a requirement for standard acceptance) but committee debates drag on for years. Whereas Python also requires trial periods outside the stable language but decisions are made much more quickly (even now that there's a steering rather than single BDFL).
Good
> Worst case you can always rollback changes.
No, you cannot. People will leave in masses. In perl they announced experiments with a mandatory use experimental :feature. You couldnt publish modules with those, or else you are at risk.
This made perl exciting and fresh. Python on the other hand constantly broke API's, and had to invent package version locks and "safe" venv's. Which became unsafe of course.
Languages and stdlib are not playgrounds. We see what came out of it with C and C++ with horrible mistakes getting standardized.
I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.
Also build system API and some other APIs change and it is super annoying.
Find it much better to use c23 with _BitInt integers and some macros and context passing for error handling.
Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.
It is understandable that breaking APIs is good for development but in most cases new API isn’t that good anyway.
And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”
Battle testing an API however requires time and the API to not constantly change.
stdlib changes as it wants from version to version. So do language features. Since zig is pre-1.0, zig foundation isn't scared of breaking changes.
So did Rust pre-1.0
Stability guarantees are a pain in the neck. You can't just break other people's code willy nilly.
> This makes zig unique. It's fun to use and it stays fresh.
You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.
> You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.
The idea with making std.Io an interface is that we're not forcing you into using green threads - or OS threads for that matter. You can (and should) bring your own std.Io implementation for embedded targets if you need standard I/O.
> once Jai comes out, Zig will become obsolete
If Jai is happy to have limited adoption (which is fine), other languages will by definition not be displaced by Jai. That is even if we accept OPs implied point, that Jai is good enough to displace Zig, without further discussion. But even that seems to be rather doubtful.
I advise to revisit HN posts about them.
Ok ok, good
> once Jai comes out
Dangit! You couldn't even make it to the end of the sentence.
Also Jai is like C++ in complexity, while Zig is similar to C, very simple language.
Carbon is vaporware so far, there’s no language that could be used yet, because they first need to solve the C++ interop and fast compilation times, that is what will shape the language, so no one is using it, because it doesn’t exist yet.
And most importantly, Zig is aiming at being a C++ replacement with the simplicity of C, it is not trying to replace C.
Any C++ or C replacement will need to win the earths of mainstream OS and game console vendors, otherwise it will remain yet another wannabe candidate.
Those have already their own languages, alongside their own C and C++ compilers, and are only now starting to warm up to Rust.
Zig or any other candidate will have a very hard time being considered.
I disagree Zig is that great deal of a language, it would have been if we were talking about 1990's programming language ecosystem, not in 21st century.
Use-after-free problems should not be something we still need to worry about, when tooling like PurifyPlus trace back to 1992.
Use-after-free is a fact of life until something kills C, but the realities of language adoption are against that. Zig seems interesting and worthwhile in offering a different perspective on the problem and does it in a way more agreeable than Rust or the like for all those who love C and are adverse to large complex languages. The realities of language adoption are as much for as against Zig, large numbers of people are still getting drawn to C and Zig seems to do a better job addressing why so many are drawn to it than the alternatives.
Your comment about gamedev focus makes no sense as that it the most hardcore segment of all the programming there is. So if a language is good for gamedev, it's good for everything else - with high performance.
I'm still in the GC camp with Go and don't see myself leaving any time soon but Zig is just rust-fugly and takes for ever to complete(it started 10 years ago, mind you). Odin is essentially complete, just lacks official spec. I like it but can' bring myself to use it as it lacks methods and I won' be going back to writing a procedural code like its 2002.
I'm curious to see Jai being released, despite having no use case for it. My initial post is merely about purposefulness, or the lack of, for named programming languages as nowadays John's name will carry more weight than Zig could ever have. so without Zig being 1.0 after a decade, and having no competitive advantage over Jai, it has no chance to survive after Jai is released. As I said, Odin will likely will as it is quite simpler, more niche language. Zig just goes directly against Jai and it will lose.
Not really. Rust was a thing long before Jai.
I'm sorry but Zig has been used to create actual production software for many companies whereas Jai has been used maybe once for a mediocre game.
That's your opinion or you have a source for that?
jai - thekla’s new game, announced but not yet released —- order of the sinking star[2]
[1]: https://jangafx.com/software/embergen
[2]: https://en.wikipedia.org/wiki/Order_of_the_Sinking_Star
https://ghostty.org
> At ZML, we are creating exciting AI produ[...]
[1] https://github.com/oven-sh/bun/tree/main/src
As for financial database concerns, if you're serious about including a project like that in your system, you have thorough correctness and performance testing stages before you commit to it. And once it passes the hurdles, at that point what difference does it make if it's written in a beta language, or a bunch of shell scripts in a trench coat, or whatever.