6 ms·

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 ar

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.

pygy_ 8mo ago
I wouldn't have expected graphic sex slang to be acceptable as a NH user name. This would translate as ~"eats pussy", where "broûter" is a verb reserved for animals feeding on grass, implying a hefty bush.
warent 8mo ago
For what it's worth, Bun is written in Zig (https://bun.sh/ https://bun.sh/). The language isn't exactly in an early stage.
- eptcyka 8mo ago
  Oh but it is.
  - tomalbrc 8mo ago
    Oh but it isn’t.
    - maleldil 8mo ago
      They just did a massive reactor that broke nearly 100% of existing code. Only an early language can do that.
      - deleted 8mo ago
        [deleted]
      - pmarreck 8mo ago
        What version are you referring to? I've had zero issues updating my zig stuff to 0.15.2 with frontier LLM assistance.
        kccqzy 8mo ago
        I’ll use Ghostty as an example because that’s the only software I use that I know is written in Zig. It’s also a moderately complex project not a toy project. Its Zig 0.15 effort started in August and was only complete in October (see first PR at https://github.com/ghostty-org/ghostty/pull/8372 https://github.com/ghostty-org/ghostty/pull/8372). And many issues were encountered and solved along the way. And of course during all of this they also encountered an issue in Zig itself: https://github.com/ziglang/zig/issues/24627 https://github.com/ziglang/zig/issues/24627
        maleldil 8mo ago
        The huge change that will be passing Io objects around like you have with Allocator.
        the_mitsuhiko 8mo ago
        0.16 changes things around dramatically.
        pmarreck 8mo ago
        Docs on this?
        maleldil 8mo ago
        Here[1]. This mentions async, but it affects every single use of IO functions. [1] https://kristoff.it/blog/zig-new-async-io/ https://kristoff.it/blog/zig-new-async-io/
        the_mitsuhiko 8mo ago
        Also anything that reads environment variables.
flohofwoe 8mo ago
IME Zig's breaking changes are quite manageable for a lot of application types since most of the breakage these days happens in the stdlib and not in the language. And if you just want do read and write files, the highlevel file-io interfaces are nearly identical, they just moved to a different namespace and now require a std.Io pointer to be passed in. And tbh, I take a 'living' language any day over a language that's ossified because of strict backward compatibility requirements. When updating a 3rd-party dependency to a new major version it's also expected that the code needs to be fixed (except in Zig those breaking changes are in the minor versions, but for 0.x that's also expected). I actually hope that even after 1.x, Zig will have a strategy to keep the stdlib lean by aggressively removing deprecated interfaces (maybe via separate stdlib interface versions, e.g. `const std = @import("std/v1");`, those versions could be slim compatibility wrappers around a single core stdlib implementation.
- pron 8mo ago
  > I take a 'living' language any day over of a language that's ossified because of strict backward compatibility requirements Maybe you would, but >95% of serious projects wouldn't. The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace, where low-level languages are commonly used, codebases typically last for over 30 years), and while such changes are manageable early on, they become less so over time. You say "strict" as if it were out of some kind of stubborn princple, where in fact backward compatibility is one of the things people who write "serious" software want most. Backward compatibility is so popular that at some point it's hard to find any feature that is in high-enough demand to justify breaking it. Even in established languages there's always a group of people who want somethng badly enough they don't mind breaking compatibility for it, but they're almost always a rather small minority. Furthermore, a good record of preserving compatibility in the past makes a language more attractive even for greenfield projects written by people who care about backward compatibility, who, in "serious" software, make up the majority. When you pick a language for such a project, the expectation of how the language will evolve over the next 20 years is a major concern on day one (a startup might not care, but most such software is not written by startups).
  - 8mo ago
radarroark 8mo ago
Pretty typical jaded HN comment there, chief. "This language's churn is more than I prefer -- why would anyone use it?" If you're not interested, just downvote and move on. Wondering out loud why anyone would actively use it ("for some reasons?") is a lame waste of bytes.
- dxdm 8mo ago
  That comment you're complaining about is a useful signal for me who only watches zig from the far periphery. I feel like I'm getting good mileage out of it, just like I do from other, different ones. I'm glad it's in the mix.
pmarreck 8mo ago
An AI will be able to handle updating your code for 95% of your breaking changes
- PaulRobinson 8mo ago
  No it won't. LLMs are good at dealing with things they've seen before, not at novel things. When novel things arise, you will either have to burn a shed ton of tokens on "reasoning", hand hold them (so you're doing advanced find and replace in this example, where you have to be incredibly precise and detailed about your language, to the point it might be quicker to just make the changes), or you have to wait until the next trained model that has seen the new pattern emerges, or quite often, all of the above.
  - zozbot234 8mo ago
    Just have to wait a few months until a new model with updated pretrained knowledge comes out.
    - weakfish 8mo ago
      Or spend those few months doing the update :-)
  - pmarreck 8mo ago
    Apologies, but your information is either outdated from lack of experience with the latest frontier models, or you don't realize the fact that 99.9% of the work you do is not novel in all capacities. Have you only used Copilot, or something? Because that's what it sounds like. Since the performance of the latest models (Opus 4.6 max-effort, gpt-5.3-Codex) is nothing short of astonishing. Real-world example: Claude isn't familiar with the latest Zig, so I had it write a language guide for 0.15.2 (here: https://gist.github.com/pmarreck/44d95e869036027f9edf332ce9a94583 https://gist.github.com/pmarreck/44d95e869036027f9edf332ce9a...) which pointed out all the differences, and that's been extremely helpful in having me not even have to touch a line of code to do the updates. On top of that, for any Zig dependency I pull in which is written to an earlier version, I have forked it and applied these updates correctly (or it has, under my guidance, really), 100% of the time. On the off chance that guide is not in its context, it has seen the expected warning or error message, googled it, and done the correct correction 100% of the time. Which is exactly what a human would do. Let's play the falsifiability game: Find me a real-world example of an upgrade to a newer API from the just-previous-to-that API that a modern LLM will fail to do correctly. Your choice of beer or coffee awaits you if you provide a link to it.
wiseowise 8mo ago
> but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga... Lol, I’ll borrow this.
lukaslalinsky 8mo ago
I really love Zig the language, but I'm distancing myself from the stdlib. I dislike the breakage, but I also started questioning the quality of the code recently. I was working on an alternative I/O framework for Zig over the last months, and I was finding many problems that eventually led to me trying to not depend on stdlib at all. Even on the code announced here, the context switching assembly is wrong, it doesn't mark all necessary registers as clobbered. I mentioned this several times to the guys. The fact that it's still unchanged just shows me lack of testing.
- vlovich123 8mo ago
  I’m confused. The register clobbering is an issue in the compiler, not in the stdlib implementation right? Or are you saying the stdlib has inline assembly in these IO implementations somewhere? I couldn’t find it and I can’t think why you’d need it. If it’s a compiler frontend-> LLVM interaction bug, I think you are commenting in the spot - it should go in a separate issue not in the PR about io_uring backend. Also, interaction bugs where a compiler frontend triggers a bug in LLVM aren’t uncommon since Rust was the first major frontend other than clang to exercise code paths. Indeed the (your?) fix in LLVM for this issue mentions Rust is impacted too. I agree with the higher level points about stability and I don’t like Zig not being a safe language in this day and age, but I think your criticism about quality is a bit harsh if your source of this complaint is that they haven’t put a workaround for an LLVM bug.
  - lukaslalinsky 8mo ago
    There is the one issue which I fixed in LLVM, but it should be fixed in Zig as well, because the clobber list in Zig is typed and gives you false impression that adding x30 there is valid. But there is also another issue, x18 is a general purpose register outside of Darwin and Windows and needs to be marked as clobbered on other systems. And yes, look at the linked changes, the stdlib has inline assembly for the context switching.
- lioeters 8mo ago
  It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library. Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and even fundamental changes in design. I think community input and feedback can be particularly valuable at this stage.
steeve 8mo ago
we (ZML) have been back to following Zig master since std.Io was introduced. It's not that bad tbh. Also most changes really feel like actual improvements to the language on a day to day basis.
rererereferred 8mo ago
No shame in waiting for 1.0. Specially if you want to read docs rather than the code itself.
- BrouteMinou 8mo ago
  Akctuyally, reading the code instead of a documentation is one of the nice part of Zig. It is such a readable language that I found it easier learning the API than most languages. Zig has this on its side. Reading the unit tests directly from the code give, most of the time, a good example too.
solatic 8mo ago
To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I really think you're missing out. There is a business case to using Zig today. True in general but in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. When the system is written in an inefficient language like Python or Node, fundamentally, you have no choice but to start to move the hotpath behind FFI and drop down to a systems language. At that point your choices are basically C, C++, Rust, or Zig. Of the four choices, Zig today is already simplest to learn, with fewer footguns, easier to work with, easier to read and write, and easier to test. And you're not going to write 100k LOC of optimized hotpath code. And when you understand the cost savings involved in reducing your compute needs by sometimes more than 90% by getting the hotpath optimized, you understand that there is very much indeed a business case to learning Zig today.
- zozbot234 8mo ago
  > ...in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. That's a very good point, actually. However... > with fewer footguns ..the Crab People[0] would definitely quibble with that particular claim of yours. [0] https://en.wikipedia.org/wiki/Crab_People https://en.wikipedia.org/wiki/Crab_People of course.
  - Tuna-Fish 8mo ago
    I would quibble with all of the claims, other than easier to learn. I really see no advantage for Zig over Rust after you get past that 2 first two weeks.
    - bbkane 8mo ago
      Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation. Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks). I'll probably stick with Rust as my "low level language" due to its safety, type system, maturity, library ecosystem, and career opportunities. But I remain jealous of Zig's willingness to do extreme things to make compilation faster.
dom96 8mo ago
You're assuming that 1.0 will bring about stability. For all we know version 1.0 could make way for version 2.0 soon after. Though perhaps the Zig developers have promised this will not happen.
DetroitThrow 8mo ago
I mean, you're right that still so many of us can't use the language yet, but I think we can still applaud progress towards major features when it's less than stable. Kudos Zig contributors!
srcreigh 8mo ago
Please stop posting 0-information-content complaints.
pstuart 8mo ago
People might be triggered by the word "worthless" but I totally get your point. I hear great things about the language but only have so many hours in the day and so many usable neurons to spend in that day. Someday it would be nice to play with it. The easiest way to embrace any new language is to have a compelling use to use it. I've not hit that point yet.
crest 8mo ago
I'm so sorry to hear about your diagnosis whatever it is :-P.
ksec 8mo ago
This is a very strange take. Isn't every pre 1.0 software like that. Heck there are some that claims to be 1.0 but then takes another 50 iteration of 1.51 before it reaches what should have been 1.0 in the first place. I am not understanding the point here, do people expect they ship 1.0 before they know it is good or ready? No wonder why software quality have deteriorated rapidly in the past 20 years.

pygy_ 8mo ago

I wouldn't have expected graphic sex slang to be acceptable as a NH user name. This would translate as ~"eats pussy", where "broûter" is a verb reserved for animals feeding on grass, implying a hefty bush.

warent 8mo ago

For what it's worth, Bun is written in Zig (https://bun.sh/ https://bun.sh/). The language isn't exactly in an early stage.

eptcyka 8mo ago
Oh but it is.
- tomalbrc 8mo ago
  Oh but it isn’t.
  - maleldil 8mo ago
    They just did a massive reactor that broke nearly 100% of existing code. Only an early language can do that.
    - deleted 8mo ago
      [deleted]
    - pmarreck 8mo ago
      What version are you referring to? I've had zero issues updating my zig stuff to 0.15.2 with frontier LLM assistance.
      - kccqzy 8mo ago
        I’ll use Ghostty as an example because that’s the only software I use that I know is written in Zig. It’s also a moderately complex project not a toy project. Its Zig 0.15 effort started in August and was only complete in October (see first PR at https://github.com/ghostty-org/ghostty/pull/8372 https://github.com/ghostty-org/ghostty/pull/8372). And many issues were encountered and solved along the way. And of course during all of this they also encountered an issue in Zig itself: https://github.com/ziglang/zig/issues/24627 https://github.com/ziglang/zig/issues/24627
      - maleldil 8mo ago
        The huge change that will be passing Io objects around like you have with Allocator.
      - the_mitsuhiko 8mo ago
        0.16 changes things around dramatically.
        pmarreck 8mo ago
        Docs on this?
        maleldil 8mo ago
        Here[1]. This mentions async, but it affects every single use of IO functions. [1] https://kristoff.it/blog/zig-new-async-io/ https://kristoff.it/blog/zig-new-async-io/
        the_mitsuhiko 8mo ago
        Also anything that reads environment variables.

flohofwoe 8mo ago

IME Zig's breaking changes are quite manageable for a lot of application types since most of the breakage these days happens in the stdlib and not in the language. And if you just want do read and write files, the highlevel file-io interfaces are nearly identical, they just moved to a different namespace and now require a std.Io pointer to be passed in. And tbh, I take a 'living' language any day over a language that's ossified because of strict backward compatibility requirements. When updating a 3rd-party dependency to a new major version it's also expected that the code needs to be fixed (except in Zig those breaking changes are in the minor versions, but for 0.x that's also expected). I actually hope that even after 1.x, Zig will have a strategy to keep the stdlib lean by aggressively removing deprecated interfaces (maybe via separate stdlib interface versions, e.g. `const std = @import("std/v1");`, those versions could be slim compatibility wrappers around a single core stdlib implementation.

pron 8mo ago
> I take a 'living' language any day over of a language that's ossified because of strict backward compatibility requirements Maybe you would, but >95% of serious projects wouldn't. The typical lifetime of a codebase intended for a lasting application is over 15 or 20 years (in industrial control or aerospace, where low-level languages are commonly used, codebases typically last for over 30 years), and while such changes are manageable early on, they become less so over time. You say "strict" as if it were out of some kind of stubborn princple, where in fact backward compatibility is one of the things people who write "serious" software want most. Backward compatibility is so popular that at some point it's hard to find any feature that is in high-enough demand to justify breaking it. Even in established languages there's always a group of people who want somethng badly enough they don't mind breaking compatibility for it, but they're almost always a rather small minority. Furthermore, a good record of preserving compatibility in the past makes a language more attractive even for greenfield projects written by people who care about backward compatibility, who, in "serious" software, make up the majority. When you pick a language for such a project, the expectation of how the language will evolve over the next 20 years is a major concern on day one (a startup might not care, but most such software is not written by startups).
- 8mo ago

radarroark 8mo ago

Pretty typical jaded HN comment there, chief. "This language's churn is more than I prefer -- why would anyone use it?" If you're not interested, just downvote and move on. Wondering out loud why anyone would actively use it ("for some reasons?") is a lame waste of bytes.

dxdm 8mo ago
That comment you're complaining about is a useful signal for me who only watches zig from the far periphery. I feel like I'm getting good mileage out of it, just like I do from other, different ones. I'm glad it's in the mix.

pmarreck 8mo ago

An AI will be able to handle updating your code for 95% of your breaking changes

PaulRobinson 8mo ago
No it won't. LLMs are good at dealing with things they've seen before, not at novel things. When novel things arise, you will either have to burn a shed ton of tokens on "reasoning", hand hold them (so you're doing advanced find and replace in this example, where you have to be incredibly precise and detailed about your language, to the point it might be quicker to just make the changes), or you have to wait until the next trained model that has seen the new pattern emerges, or quite often, all of the above.
- zozbot234 8mo ago
  Just have to wait a few months until a new model with updated pretrained knowledge comes out.
  - weakfish 8mo ago
    Or spend those few months doing the update :-)
- pmarreck 8mo ago
  Apologies, but your information is either outdated from lack of experience with the latest frontier models, or you don't realize the fact that 99.9% of the work you do is not novel in all capacities. Have you only used Copilot, or something? Because that's what it sounds like. Since the performance of the latest models (Opus 4.6 max-effort, gpt-5.3-Codex) is nothing short of astonishing. Real-world example: Claude isn't familiar with the latest Zig, so I had it write a language guide for 0.15.2 (here: https://gist.github.com/pmarreck/44d95e869036027f9edf332ce9a94583 https://gist.github.com/pmarreck/44d95e869036027f9edf332ce9a...) which pointed out all the differences, and that's been extremely helpful in having me not even have to touch a line of code to do the updates. On top of that, for any Zig dependency I pull in which is written to an earlier version, I have forked it and applied these updates correctly (or it has, under my guidance, really), 100% of the time. On the off chance that guide is not in its context, it has seen the expected warning or error message, googled it, and done the correct correction 100% of the time. Which is exactly what a human would do. Let's play the falsifiability game: Find me a real-world example of an upgrade to a newer API from the just-previous-to-that API that a modern LLM will fail to do correctly. Your choice of beer or coffee awaits you if you provide a link to it.

wiseowise 8mo ago

> but for the Grand Majority of the devs in here, it's like an announcement that it's raining in Kuldîga... Lol, I’ll borrow this.

lukaslalinsky 8mo ago

I really love Zig the language, but I'm distancing myself from the stdlib. I dislike the breakage, but I also started questioning the quality of the code recently. I was working on an alternative I/O framework for Zig over the last months, and I was finding many problems that eventually led to me trying to not depend on stdlib at all. Even on the code announced here, the context switching assembly is wrong, it doesn't mark all necessary registers as clobbered. I mentioned this several times to the guys. The fact that it's still unchanged just shows me lack of testing.

vlovich123 8mo ago
I’m confused. The register clobbering is an issue in the compiler, not in the stdlib implementation right? Or are you saying the stdlib has inline assembly in these IO implementations somewhere? I couldn’t find it and I can’t think why you’d need it. If it’s a compiler frontend-> LLVM interaction bug, I think you are commenting in the spot - it should go in a separate issue not in the PR about io_uring backend. Also, interaction bugs where a compiler frontend triggers a bug in LLVM aren’t uncommon since Rust was the first major frontend other than clang to exercise code paths. Indeed the (your?) fix in LLVM for this issue mentions Rust is impacted too. I agree with the higher level points about stability and I don’t like Zig not being a safe language in this day and age, but I think your criticism about quality is a bit harsh if your source of this complaint is that they haven’t put a workaround for an LLVM bug.
- lukaslalinsky 8mo ago
  There is the one issue which I fixed in LLVM, but it should be fixed in Zig as well, because the clobber list in Zig is typed and gives you false impression that adding x30 there is valid. But there is also another issue, x18 is a general purpose register outside of Darwin and Windows and needs to be marked as clobbered on other systems. And yes, look at the linked changes, the stdlib has inline assembly for the context switching.
lioeters 8mo ago
It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library. Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and even fundamental changes in design. I think community input and feedback can be particularly valuable at this stage.

steeve 8mo ago

we (ZML) have been back to following Zig master since std.Io was introduced. It's not that bad tbh. Also most changes really feel like actual improvements to the language on a day to day basis.

rererereferred 8mo ago

No shame in waiting for 1.0. Specially if you want to read docs rather than the code itself.

BrouteMinou 8mo ago
Akctuyally, reading the code instead of a documentation is one of the nice part of Zig. It is such a readable language that I found it easier learning the API than most languages. Zig has this on its side. Reading the unit tests directly from the code give, most of the time, a good example too.

solatic 8mo ago

To each his own, but while I can certainly understand the hesitancy of an architect to pick Zig for a project that is projected to hit 100k+ lines of code, I really think you're missing out. There is a business case to using Zig today. True in general but in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. When the system is written in an inefficient language like Python or Node, fundamentally, you have no choice but to start to move the hotpath behind FFI and drop down to a systems language. At that point your choices are basically C, C++, Rust, or Zig. Of the four choices, Zig today is already simplest to learn, with fewer footguns, easier to work with, easier to read and write, and easier to test. And you're not going to write 100k LOC of optimized hotpath code. And when you understand the cost savings involved in reducing your compute needs by sometimes more than 90% by getting the hotpath optimized, you understand that there is very much indeed a business case to learning Zig today.

zozbot234 8mo ago
> ...in the cloud especially, saving server resources can make a significant impact on the bottom line. There are not nearly enough performance engineers who understand how to take inefficient systems and make improvements to move towards theoretical maximum efficiency. That's a very good point, actually. However... > with fewer footguns ..the Crab People[0] would definitely quibble with that particular claim of yours. [0] https://en.wikipedia.org/wiki/Crab_People https://en.wikipedia.org/wiki/Crab_People of course.
- Tuna-Fish 8mo ago
  I would quibble with all of the claims, other than easier to learn. I really see no advantage for Zig over Rust after you get past that 2 first two weeks.
  - bbkane 8mo ago
    Coming from Go, I'm really disappointed in Rust compiler times. I realize they're comparable to C++, and you can structure your crates to minimize compile times, but I don't care. I want instant compilation. Zig is trying to get me instant compilation and I see that as a huge advantage for Zig (even past the first 2 weeks). I'll probably stick with Rust as my "low level language" due to its safety, type system, maturity, library ecosystem, and career opportunities. But I remain jealous of Zig's willingness to do extreme things to make compilation faster.

dom96 8mo ago

You're assuming that 1.0 will bring about stability. For all we know version 1.0 could make way for version 2.0 soon after. Though perhaps the Zig developers have promised this will not happen.

DetroitThrow 8mo ago

I mean, you're right that still so many of us can't use the language yet, but I think we can still applaud progress towards major features when it's less than stable. Kudos Zig contributors!

srcreigh 8mo ago

Please stop posting 0-information-content complaints.

pstuart 8mo ago

People might be triggered by the word "worthless" but I totally get your point. I hear great things about the language but only have so many hours in the day and so many usable neurons to spend in that day. Someday it would be nice to play with it. The easiest way to embrace any new language is to have a compelling use to use it. I've not hit that point yet.

crest 8mo ago

I'm so sorry to hear about your diagnosis whatever it is :-P.

ksec 8mo ago

This is a very strange take. Isn't every pre 1.0 software like that. Heck there are some that claims to be 1.0 but then takes another 50 iteration of 1.51 before it reaches what should have been 1.0 in the first place. I am not understanding the point here, do people expect they ship 1.0 before they know it is good or ready? No wonder why software quality have deteriorated rapidly in the past 20 years.