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.
Is the completeness of each API formally documented anywhere? Maybe I missed something but it doesn't seem like it is, in which case the only way to know would be to follow what's happening behind the scenes.
The migration pain will be the same once it launches unless they revert back, which does not seem likely at all.
But the point is: potentially every API is unstable.
From what I can tell pretty much everything can be broken at any point in time. So really the only actual advise here is not to use the language at all which is not reasonable.
> llms don't help when trying to make sense of the above
That has not been my experience. LLMs were what enabled me to upgrade to 0.16 experimentally at all.
> 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.
No, that is unnecessary gatekeeping. 0.16 will become stable at one point and I don't want to wait until then to figure out what will happen. That's not how I used Rust when it was early (I always also tried nightlies) and that line of thinking just generally does not make any sense to me.
The reality is that Zig has very little desire to stabilize at the moment.
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).
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.
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”
> 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.
I was a bit too frustrated with all these changes and zig wasn’t the right choice for my particular use case then.
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.
The nice thing about async is that it tells you threads are cheap to spawn. By making everything colourless you implicitly assume everything is green thread.
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.
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.
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.
You really should learn a few new languages if you think that’s remotely true. For example, Lisp macros are the distant ancestors of most metaprogramming techniques, dating from the 60s. But there are many similar techniques that precede Zig comptime and Jai, like D’s mixins and templates, which together have very similar power to comptime. There are also Nim macros which I believe also precede Jai. Even the C preprocessor could probably be considered an inspiration for anyone creating a C competitor before we need to invoke Jai ideas.
You’ve made this claim on here before and when I asked you to substantiate it with a source you were completely unable to.
That's your opinion or you have a source for that?
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.
> 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.
See Python 2->3, Rust async traits, Go generics, C++... basically everything.
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
> At ZML, we are creating exciting AI produ[...]
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.