Discussion
Devlog
h4ch1: I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important.How's your experience with the constantly changing language? How're your update/rewrite cycles looking like? Are there cases where packages you may use fall behind the language?I know Bun's using zig to a degree of success, was wondering how the rest were doing.
Cloudef: The language itself does not change much, but the std does. It depends on individuals, but some people rely less on the std, some copy the old code that they still need.> Are there cases where packages you may use fall behind the language?Using third party packages is quite problematic yes. I don't recommend using them too much personally, unless you want to make more work for yourself.
latch: Zig 0.15 is pretty stable. The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path. I've yet to find exactly why this [only sometimes] causes such a crash, but they're a real pain to figure out over a large changeset. `zig ast-check` sometimes catches the error, else Claude's pretty good at spotting where I accidentally re-used a variable name (again, 90% of the time I do that, it's an easy error, but the other 10%, I get a message-less compiler crash). It sounds like the changes in the OP might be specifically addressing these types of issues.Also, my .zig-cache is currently at 173GB, which causes some issues on the small Linux ARM VPS I test with.As for upgrades. I upgraded lightpanda to 0.14 then 0.15 and it was fine. I think for lightpanda, the 0.16 changes might not be too bad, with the only potential issue coming from our use of libcurl and our small websocket server (for CDP connections). Those layers are relatively isolated / abstracted, so I'm hopeful.As a library developer, I've given up following / tracking 0.16. For one, the change don't resonate with me, and for another, it's changing far too fast. I don't think anyone expects 0.16 support in a library right now. I've gotten PRs for my "dev" branches from a few brave souls and everyone seems happy with that arrangement.
Escapade5160: I recently tried to learn it and found it frustrating. A lot of docs are for 0.15 but the latest is (or was) 0.16 which changed a lot of std so none of the existing write ups were valid anymore. I plan to revisit once it gets more stable because I do like it when I get it to work.
Cloudef: 0.16 is the development version. 0.15.2 is latest release.
quag: That .zig-cache seems massive to me. I keep mine on a tmpfs and remove it every time the tmpfs is full.Do you see any major problems when you remove your .zig-cache and start over?
latch: Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.
throwaway17_17: Congratulations to the dev, a 30,000 line PR for a language compiler (and a very much non-trivial compiler) is a feat to be proud of. But a change of this magnitude is a serious bit of development and gave me pause.I understand both of the following:1. Language development is a tricky subject, in general, but especially for those languages looking for wide adoption or hoping for ‘generational’ (program life span being measured in multiple decades) usage in infrastructure, etc.2) Zig is a young-ish language, not at 1.0, and explicitly evolving as of the posting of TFAWith those points as caveats, I find the casualness of the following (from the codeburg post linked on the devlog) surprising:‘’’This branch changes the semantics of "uninstantiable" types (things like noreturn, that is, types which contain no values). I wasn't originally planning to do this here, but matching the semantics of master was pretty difficult because the existing semantics don't make much sense.’’’I don’t know Zig’s particular strategy and terminology for language and compiler development, but I would assume the usage of ‘branch’ here implies this is not a change fully/formally adopted by the language but more a fully implemented proposal. Even if it is just a proposal for change, the large scale of the rewrite and clear implication that the author expects it to be well received strikes me as uncommon confidence. Changing the semantics of a language with any production use is nearly definitionally MAJOR, to just blithely state your PR changes semantics and proceed with no deep discussion (which could have previously happened, IDK) or serious justification or statements concerning the limited effect of those changes is not something I have experienced watching the evolution (or de-evolution) of other less ‘serious’ languages.Is this a “this dev” thing, a Zig thing, or am just out of touch with modern language (or even larger scale development) projects?Also, not particularly important or really significant to the overall thrust of TFA, but the author uses the phrase “modern Zig”, which given Zig’s age and seeming rate of change currently struck me as a very funny turn of phrase.
smj-edison: mlugg is one of the core contributors of Zig, and is a member of the Zig foundation iirc. They've been wanting to work on dependency resolution for a while now, so I'm really glad they're cleaning this up (I've been bitten before by unclear circular dependency errors). There's not a formal language spec yet, since it's moving pretty fast, but tbh I don't see the need for a standard, since that's not one of their goals currently.
AndyKelley: Originally, Zig's type system was less disciplined in terms of the "zero" type (also known as "noreturn").This was proposed, discussed, and accepted here: https://github.com/ziglang/zig/issues/3257Later, Matthew Lugg made a follow-up proposal, which was discussed both publicly and in ZSF core team meetings. https://github.com/ziglang/zig/issues/15909He writes:> A (fairly uncontroversial) subset of this behavior was implemented in [the changeset we are discussing]. I'll close this for now, though I'll probably end up revisiting these semantics more precisely at some point, in which case I'll open a new issue on Codeberg.I don't know how evident this is to the casual HN reader, but to me this changeset very obviously moves Zig the language from experimental territory a large degree towards being formally specified, because it makes type resolution a Directed Acyclic Graph. Just look at how many bugs it resolved to get a feel for it. This changeset alone will make the next release of the compiler significantly more robust.Now, I like talking about its design and development, but all that being said, Zig project does not aim for full transparency. It says right there in the README:> Zig is Free and Open Source Software. We welcome bug reports and patches from everyone. However, keep in mind that Zig governance is BDFN (Benevolent Dictator For Now) which means that Andrew Kelley has final say on the design and implementation of everything.It's up to you to decide whether the language and project are in trustworthy hands. I can tell you this much: we (the dev team) have a strong vision and we care deeply about the project, both to fulfill our own dreams as well as those of our esteemed users whom we serve[1]. Furthermore, as a 501(c)(3) non-profit we have no profit motive to cause enshittification.[1]: https://ziglang.org/documentation/master/#ZenIt's been incredible working with Matthew. I hope I can have the pleasure to continue to call him my colleague for many years to come.
Zambyte: Using third party packages has gotten a lot easier with the changes described in this devlog https://ziglang.org/devlog/2026/#2026-02-06
rowanG077: Just thinking out loud here, perhaps behavior like this has been more normalized because of the total shitshow that C is. Which followed all these supposedly correct rules.
jibal: > I don’t know Zig’s particular strategy and terminology for language and compiler developmentIndeed you don't ... perhaps you should have asked.> I would assumeGenerally a bad idea.> which could have previously happened, IDKIndeed you don't. Perhaps you should have asked.Check the response from the language BDFN, Andrew Kelley.
rtfeldman: [delayed]
