I don't want to be the negative guy, but this is news about two unfinished implementations. There is a lot of work needed for this to be considered done. For example, no networking in the GCD version yet. And as these are being implemented, the interface stops being an interface, the vtable keeps growing, and it's just the current snapshot of what's needed by the std implementations.
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.
Contrary to the neggies, I am positive in Zigs effort to iterate & improve.
Right now there is no language that is good at io-uring. There are ok offerings, but nothing really has modern async joy that works with uring.
Whoever hammers out a good solution here is going to have a massive leg up. Rust is amazing in so many ways but it has been quite a brutal road to trying to support io-uring ok, and efforts are still a bit primitive, shall we say. If Zig can nail this down that would be fantastic!!
I would way rather Zig keep learning and keep changing, keep making new and better. Than to have it try to appease those who are too conservative for the project, unwilling to accept change and improvement, people focused on stability. It takes a lot of learning to make really good systems, to play with fit and finish. Zig is doing the good work. Imo we ought be thankful.
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.
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.
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.
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.
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.
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.
> 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).
> 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.
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”
It sounds like you expected 1.0 stability from a language that isn't 1.0.
> I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.
From the 0.14.0 release notes:
> Zig 0.14.0 ships with an integrated fuzzer. It is alpha quality status, which means that using it requires participating in the development process.
How could we possibly have been more explicit?
Fuzzing will be a major component of Zig's testing strategy in the long term, but we clearly haven't had the time to get it into shape yet. But we also didn't claim to have done!
> 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.
I mean, to be fair, most compiled languages can't give you 100% accurate source-level stack traces in release builds. But that aside, we have actually invested quite a lot of effort into std.debug in the 0.16.0 release cycle, and you should now get significantly better and more reliable stack traces on all supported platforms. If you encounter a case where you don't, file a bug.
> 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”
I acknowledge that API churn can be annoying, but it would be weird not to aim for perfection prior to 1.0.
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.
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?
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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".
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.
I don't want to be the negative guy, but this is news about two unfinished implementations. There is a lot of work needed for this to be considered done. For example, no networking in the GCD version yet. And as these are being implemented, the interface stops being an interface, the vtable keeps growing, and it's just the current snapshot of what's needed by the std implementations.
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.
[delayed]
Contrary to the neggies, I am positive in Zigs effort to iterate & improve.
Right now there is no language that is good at io-uring. There are ok offerings, but nothing really has modern async joy that works with uring.
Whoever hammers out a good solution here is going to have a massive leg up. Rust is amazing in so many ways but it has been quite a brutal road to trying to support io-uring ok, and efforts are still a bit primitive, shall we say. If Zig can nail this down that would be fantastic!!
I would way rather Zig keep learning and keep changing, keep making new and better. Than to have it try to appease those who are too conservative for the project, unwilling to accept change and improvement, people focused on stability. It takes a lot of learning to make really good systems, to play with fit and finish. Zig is doing the good work. Imo we ought be thankful.
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.
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.
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.
Obviously, that comes with the language being in beta. If you don't want things broken, use a complete language.
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.
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.
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.
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.
I think it benefits the overall ecosystem for them to experiment so other languages can take what works
> 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).
> 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.
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”
It sounds like you expected 1.0 stability from a language that isn't 1.0.
> I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.
From the 0.14.0 release notes:
> Zig 0.14.0 ships with an integrated fuzzer. It is alpha quality status, which means that using it requires participating in the development process.
How could we possibly have been more explicit?
Fuzzing will be a major component of Zig's testing strategy in the long term, but we clearly haven't had the time to get it into shape yet. But we also didn't claim to have done!
> 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.
I mean, to be fair, most compiled languages can't give you 100% accurate source-level stack traces in release builds. But that aside, we have actually invested quite a lot of effort into std.debug in the 0.16.0 release cycle, and you should now get significantly better and more reliable stack traces on all supported platforms. If you encounter a case where you don't, file a bug.
> 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”
I acknowledge that API churn can be annoying, but it would be weird not to aim for perfection prior to 1.0.
> 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.
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.
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?
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.
0.16's IO API changes might be that cleanup.
> 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.
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.
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.
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.
>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.
I think you meant to say Jai, not Zig.
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.
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.
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.
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.
For that to matter OS vendors that only care about C on their platforms, have to also care about Zig.
Otherwise the only users are going to be the ones happy to do some yak shaving instead of the actual application code with the vendor tools.
It also ignores that C doesn't stand still, the competition is C2y, not C89.
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.
> 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.
> 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?
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.
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.
> Remember that it was Jai that inspired all these new languages.
Not really. Rust was a thing long before Jai.
> Jokes aside
Ok ok, good
> once Jai comes out
Dangit! You couldn't even make it to the end of the sentence.
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.
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.
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.
Agreed, however I also think Zig will be another Coffee Script, PureScript, Elm,...
I advise to revisit HN posts about them.
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.
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.
odin - jangafx’s embergen[1]
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
That's next to nothing for Jai.
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.
Any backwards compatible language will accumulate hindsight errors. It's practically inevitable.
Can you elaborate? Zig has a lot of traction already.
Except for Tiger Beetle customers and the few ones using Bun, what traction?
Ghostty
https://ghostty.org
Another one to the list, however it hardly sounds like a killer application.
Ghostty.
ZML
What is even that? Not bothering to Google for it, which shows how irrelevant it is.
Good call, for bad reasons.
> At ZML, we are creating exciting AI produ[...]
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".
You can actually go and read the source yourself [1]. If Bun is "just a wrapper", then surely Node.js and Deno are too?
[1] https://github.com/oven-sh/bun/tree/main/src
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.
Let it come out before we get to chest beating. We are talking about shipped features in Zig here.
WalterBright reply in 3...2...1...
You're right that zig is vaporware - not because of other languages - but because programming is going away entirely.
> Both of these are based on userspace stack switching, sometimes called “fibers”, “stackful coroutines”, or “green threads”.
Haven’t looked into MacOS internals for a while, happy to see they stuck to GCD, great middle ground for parallelisation