7 ms·

Isn't this a bad time to be embracing Zig? It's currently going through an intrusive upheaval of its I/O model. My impression is that it was going to take a f

Isn't this a bad time to be embracing Zig? It's currently going through an intrusive upheaval of its I/O model. My impression is that it was going to take a few years for things to shake out. Is that wrong?

geysersam 1y ago
What's a few years? They go by in the blink of an eye. Zig is a perfectly usable language. People who want to use it will, those who don't won't.
- tonyhart7 1y ago
  only for hobby project
  - nesarkvechnep 1y ago
    You or in general? Because, you know, this is like, your opinion, man.
    - tonyhart7 1y ago
      My Opinion??? how about you goes to Zig github and check how progress of the language it literally there and its still beta test and not fit for production let alone have mature ecosystem
      - dns_snek 1y ago
        Yes, your opinion. I run it in production and everything I've built with it has been rock solid (aside from my own bugs). I haven't touched a few of my projects in a few years and they work fine, but if I wanted to update them to the latest version of Zig I'd have a bit of work ahead of me. That's it.
        tonyhart7 1y ago
        [flagged]
        dns_snek 1y ago
        Can you rage bait somewhere else?
        tonyhart7 1y ago
        since when stating fact is rage bait????
  - scuff3d 1y ago
    TigerBeetle, Bun, and Ghostty all beg to differ...
    - tonyhart7 1y ago
      [flagged]
      - samtheprogram 1y ago
        Bun is 100% fine in production. And you should be using it instead of transpiling TypeScript unless there’s some other barrier to using it.
        tonyhart7 1y ago
        I am not trying to dunk on this project all of these project is great but we cant ignore that Zig is not enter phase where we can guarantee stable API compability
        scuff3d 1y ago
        Nobody is denying that? Andrew Kelly and the Zig team have been extremely clear that they are okay making break changes. So if you're choosing to use it in large projects, as some have, you're taking that risk. I think it speaks volumes that these projects chose to use it, and speak very highly of it, despite the fact that it's still pre 1.0.
        tonyhart7 1y ago
        "Nobody is denying that?" seems like you missing a lot of comment on this tree
        scuff3d 1y ago
        Care to point out a few?
      - deleted 1y ago
- attila-lendvai 1y ago
  following upstream is overrated since we have good package managers and version control. it's completely feasible to stick to something that works for you, and only update/port/rewrite when it makes sense. what matters is the overall cost.
  - kunley 1y ago
    Hmm, if one writes a library Zetalib for the language Frob v0.14 and then Frob v0.15 introduces breaking changes that everyone else is going to adapt to, then well, package managers and version control is going to help indeed - they will help in staying in a void as no one will use Zetalib anymore because of the older Frob.
    - all2 1y ago
      For libs, yes, for applications dev, no. I would expect fixing an application to an older version would be just fine, so long as you don't need newer language features. If newer language features are a requirement, I would expect that would drive refactoring or selecting a different implementation language entirely if refactoring would prove to be too onerous.
grayhatter 1y ago
IMO, it's very wrong. Zig's language is not drastically changing, it's adding a new, *very* powerful API, which similar to how most everything in zig passes an allocator as a function param, soon functions that want to do IO, will accept an object that will provide the desired abstraction, so that callers can define the ideal implementation. In other words, the only reason to not use zig if you detest upgrading or improving your code. Code you write today will still work tomorrow. Code you write tomorrow, will likely have a new Io interface, because you want to use that standard abstraction. But, if you don't want to use it, all your existing code will still work. Just like today, if you want to alloc, but don't want to pass an `Allocator` you can call std.heap.page_allocator.alloc from anywhere. But because that abstraction is so useful, and zig supports it so ergonomically, everyone writes code that provides that improved API side note; I was worried about upgrading all my code to interface with the new Reader/Writer API that's already mostly stable in 0.15.2, but even though I had to add a few lines in many existing projects to upgrade. I find myself optionally choosing to refactor a lot of functions because the new API results is code that is SO much better. Both in readability, but also performance. Do I have to refactor? No, the old API works flawlessly, but the new API is simply more ergonomic, more performant and easier to read and reason about. I'm doing it because I want to, not because I have to. Everyone knows' a red diff is the best diff, and the new std.Io API exposes an easier way to do things. Still, like everything in zig, it allows you to write the code that you want to write. But if you want to do it yourself, that's fully supported too!
- do_not_redeem 1y ago
  This isn't quite accurate. If you look at the new IO branch[1] you'll see (for example) most of the std.fs functions are gone, and most of what's left is deprecated. The plan is for all file/network access, mutexes, etc to be accessible only through the Io interface. It'll be a big migration once 0.16 drops. [1]: https://github.com/ziglang/zig/blob/init-std.Io/lib/std/fs.zig https://github.com/ziglang/zig/blob/init-std.Io/lib/std/fs.z... > Do I have to refactor? No, the old API works flawlessly The old API was deleted though? If you're saying it's possible to copy/paste the old stdlib into your project and maintain the old abstractions forward through the ongoing language changes, sure that's possible, but I don't think many people will want to fork std. I copy/pasted some stuff temporarily to make the 0.15 migration easier, but maintaining it forever would be swimming upstream for no reason.
laserbeam 1y ago
Kind of is a bad idea. Even the author’s library is not using the latest zig IO features and is planning for big changes with 0.16. From the readme of the repo: > Additionally, when Zig 0.16 is released with the std.Io interface, I will implement that as well, allowing you to use the entire standard library with this runtime. Unrelated to this library, I plan to do lots of IO with Zig and will wait for 0.16. Your intuition may decide otherwise and that’s ok.
lukaslalinsky 1y ago
It really depends on what you are doing, but if it's something related to I/O and you embrace the buffered reader/writer interfaces introduced in Zig 0.15, I think not much is going to change. You might need changes on how you get those interfaces, but the core of your code is unchanged.
dualogy 1y ago
> My impression is that it was going to take a few years for things to shake out. Is that wrong? I had that very impression in early 2020 after some months of Zigging (and being burned by constant breaking changes), and left, deciding "I'll check it out again in a few years." I had some intuition it might be one of these forever-refactoring eternal-tinker-and-rewrite fests and here I am 5 years later, still lurking for that 1.0 from the sidelines, while staying in Go or C depending on the nature of the thing at hand. That's not to say it'll never get there, it's a vibrant project prioritizing making the best design decisions rather than mere Shipping Asap. For a C-replacement that's the right spirit, in principle. But whether there's inbuilt immunity to engineers falling prey to their forever-refine-and-resculpt I can't tell. I find it a great project to wait for leisurely (=
d-mason 11mo ago
I am working on a ~15K loc project in Zig and have been for over 3 years. Most times a new version comes out there is nothing to do. A half dozen times I've spent as long as half a day updating references to the standard library. There have been 3 significant problems (2 of them LLVM changes that Zig hasn't adapted to) that have been multi-day frustrations. We are currently holding at 0.15.1, partly because of the I/O changes (although we're not heavy users of I/O), and partly waiting for the native backend implementations to stabilize. All that said, we remain very happy with the choice of Zig - it has so many advantages over C/C++ and even (for our application) Rust (we have about 3K LOC in our original Rust implementation). Is Zig fully mature? Certainly not! Is it mature enough to be highly productive? Certainly!

geysersam 1y ago

What's a few years? They go by in the blink of an eye. Zig is a perfectly usable language. People who want to use it will, those who don't won't.

tonyhart7 1y ago
only for hobby project
- nesarkvechnep 1y ago
  You or in general? Because, you know, this is like, your opinion, man.
  - tonyhart7 1y ago
    My Opinion??? how about you goes to Zig github and check how progress of the language it literally there and its still beta test and not fit for production let alone have mature ecosystem
    - dns_snek 1y ago
      Yes, your opinion. I run it in production and everything I've built with it has been rock solid (aside from my own bugs). I haven't touched a few of my projects in a few years and they work fine, but if I wanted to update them to the latest version of Zig I'd have a bit of work ahead of me. That's it.
      - tonyhart7 1y ago
        [flagged]
        dns_snek 1y ago
        Can you rage bait somewhere else?
        tonyhart7 1y ago
        since when stating fact is rage bait????
- scuff3d 1y ago
  TigerBeetle, Bun, and Ghostty all beg to differ...
  - tonyhart7 1y ago
    [flagged]
    - samtheprogram 1y ago
      Bun is 100% fine in production. And you should be using it instead of transpiling TypeScript unless there’s some other barrier to using it.
      - tonyhart7 1y ago
        I am not trying to dunk on this project all of these project is great but we cant ignore that Zig is not enter phase where we can guarantee stable API compability
        scuff3d 1y ago
        Nobody is denying that? Andrew Kelly and the Zig team have been extremely clear that they are okay making break changes. So if you're choosing to use it in large projects, as some have, you're taking that risk. I think it speaks volumes that these projects chose to use it, and speak very highly of it, despite the fact that it's still pre 1.0.
        tonyhart7 1y ago
        "Nobody is denying that?" seems like you missing a lot of comment on this tree
        scuff3d 1y ago
        Care to point out a few?
    - deleted 1y ago
attila-lendvai 1y ago
following upstream is overrated since we have good package managers and version control. it's completely feasible to stick to something that works for you, and only update/port/rewrite when it makes sense. what matters is the overall cost.
- kunley 1y ago
  Hmm, if one writes a library Zetalib for the language Frob v0.14 and then Frob v0.15 introduces breaking changes that everyone else is going to adapt to, then well, package managers and version control is going to help indeed - they will help in staying in a void as no one will use Zetalib anymore because of the older Frob.
  - all2 1y ago
    For libs, yes, for applications dev, no. I would expect fixing an application to an older version would be just fine, so long as you don't need newer language features. If newer language features are a requirement, I would expect that would drive refactoring or selecting a different implementation language entirely if refactoring would prove to be too onerous.

grayhatter 1y ago

IMO, it's very wrong. Zig's language is not drastically changing, it's adding a new, *very* powerful API, which similar to how most everything in zig passes an allocator as a function param, soon functions that want to do IO, will accept an object that will provide the desired abstraction, so that callers can define the ideal implementation. In other words, the only reason to not use zig if you detest upgrading or improving your code. Code you write today will still work tomorrow. Code you write tomorrow, will likely have a new Io interface, because you want to use that standard abstraction. But, if you don't want to use it, all your existing code will still work. Just like today, if you want to alloc, but don't want to pass an `Allocator` you can call std.heap.page_allocator.alloc from anywhere. But because that abstraction is so useful, and zig supports it so ergonomically, everyone writes code that provides that improved API side note; I was worried about upgrading all my code to interface with the new Reader/Writer API that's already mostly stable in 0.15.2, but even though I had to add a few lines in many existing projects to upgrade. I find myself optionally choosing to refactor a lot of functions because the new API results is code that is SO much better. Both in readability, but also performance. Do I have to refactor? No, the old API works flawlessly, but the new API is simply more ergonomic, more performant and easier to read and reason about. I'm doing it because I want to, not because I have to. Everyone knows' a red diff is the best diff, and the new std.Io API exposes an easier way to do things. Still, like everything in zig, it allows you to write the code that you want to write. But if you want to do it yourself, that's fully supported too!

do_not_redeem 1y ago
This isn't quite accurate. If you look at the new IO branch[1] you'll see (for example) most of the std.fs functions are gone, and most of what's left is deprecated. The plan is for all file/network access, mutexes, etc to be accessible only through the Io interface. It'll be a big migration once 0.16 drops. [1]: https://github.com/ziglang/zig/blob/init-std.Io/lib/std/fs.zig https://github.com/ziglang/zig/blob/init-std.Io/lib/std/fs.z... > Do I have to refactor? No, the old API works flawlessly The old API was deleted though? If you're saying it's possible to copy/paste the old stdlib into your project and maintain the old abstractions forward through the ongoing language changes, sure that's possible, but I don't think many people will want to fork std. I copy/pasted some stuff temporarily to make the 0.15 migration easier, but maintaining it forever would be swimming upstream for no reason.

laserbeam 1y ago

Kind of is a bad idea. Even the author’s library is not using the latest zig IO features and is planning for big changes with 0.16. From the readme of the repo: > Additionally, when Zig 0.16 is released with the std.Io interface, I will implement that as well, allowing you to use the entire standard library with this runtime. Unrelated to this library, I plan to do lots of IO with Zig and will wait for 0.16. Your intuition may decide otherwise and that’s ok.

lukaslalinsky 1y ago

It really depends on what you are doing, but if it's something related to I/O and you embrace the buffered reader/writer interfaces introduced in Zig 0.15, I think not much is going to change. You might need changes on how you get those interfaces, but the core of your code is unchanged.

dualogy 1y ago

> My impression is that it was going to take a few years for things to shake out. Is that wrong? I had that very impression in early 2020 after some months of Zigging (and being burned by constant breaking changes), and left, deciding "I'll check it out again in a few years." I had some intuition it might be one of these forever-refactoring eternal-tinker-and-rewrite fests and here I am 5 years later, still lurking for that 1.0 from the sidelines, while staying in Go or C depending on the nature of the thing at hand. That's not to say it'll never get there, it's a vibrant project prioritizing making the best design decisions rather than mere Shipping Asap. For a C-replacement that's the right spirit, in principle. But whether there's inbuilt immunity to engineers falling prey to their forever-refine-and-resculpt I can't tell. I find it a great project to wait for leisurely (=

d-mason 11mo ago

I am working on a ~15K loc project in Zig and have been for over 3 years. Most times a new version comes out there is nothing to do. A half dozen times I've spent as long as half a day updating references to the standard library. There have been 3 significant problems (2 of them LLVM changes that Zig hasn't adapted to) that have been multi-day frustrations. We are currently holding at 0.15.1, partly because of the I/O changes (although we're not heavy users of I/O), and partly waiting for the native backend implementations to stabilize. All that said, we remain very happy with the choice of Zig - it has so many advantages over C/C++ and even (for our application) Rust (we have about 3K LOC in our original Rust implementation). Is Zig fully mature? Certainly not! Is it mature enough to be highly productive? Certainly!