5 ms·

Zig 0.16.0 Release Notes

166 points by ska80 6mo ago

sionisrecur 6mo ago
The "Juicy Main" looks like a very nice QoL feature. Gets rid of all the boilerplate for allocators and argv.
- mihaelm 6mo ago
  It's the dark horse of this release as CLI parsing can also be more easily built on top of it. There's a couple of proposals floating around now, so I hope we get something soon-ish (maybe in 0.18 since a short cyle is planned for 0.17).
  - fredyr 6mo ago
    This sounds interesting to me - could you elaborate a little on what things are in those proposals?
    - mihaelm 6mo ago
      Sure, this is the issue tracking the work: https://codeberg.org/ziglang/zig/issues/30677 https://codeberg.org/ziglang/zig/issues/30677 The idea is to offer some kind of CLI parsing in the std. It says minimal, but the discussion also veers into some more advanced options. The discussion resulted in two PRs (that I know of): - Type-driven: https://codeberg.org/ziglang/zig/issues/30677 https://codeberg.org/ziglang/zig/issues/30677 @dotcarmen extracted it into a package (https://codeberg.org/dotcarmen/clip https://codeberg.org/dotcarmen/clip) so people could more easily try it out. - Composition-based: https://codeberg.org/ziglang/zig/pulls/31620 https://codeberg.org/ziglang/zig/pulls/31620 If you're familiar with Rust's clap, it's a bit like derive vs builder API. You can also see how each approach would look in practice if you inspect the diff for the "tools" directory on the PRs.
      - fredyr 6mo ago
        Thanks!
      - anttiharju 6mo ago
        clap's derive is so nice
- portly 6mo ago
  Do I get it right that this is everything you need for a typical CLI tool?
  - nesarkvechnep 6mo ago
    You got that right.
    - portly 6mo ago
      That's clean.
_bohm 6mo ago
I've been waiting eagerly for this release ever since the new Io interface was announced. Pumped to start working on some new projects with this! Love this line from the release notes: > Lo! Lest one learn a lone release lesson, let proclaim: "cancelation" should seriously only be spelt thusly (single "l"). Let not evil, godless liars lead afoul.
xeubie 6mo ago
What a banger of a release. The new `Io` interface was a huge breaking change for my project, but I made the transition. Zig seems to be pulling the same trick it pulled with allocators: just make it an explicit value that you pass around. Explicit allocators felt obviously right in retrospect, and so far this feels obviously right too.
- mihaelm 6mo ago
  The approach feels like a natural extension of Zig's philosophy about explicitness around low-level operations (no hidden control flow, no hidden memory allocations, etc.). Your function can be blocking? Communicate that through the function signature! Very in style for the language.
mihaelm 6mo ago
Obviously, I/O as an interface is the headliner here, but there are lots of other goodies to pay attention to, such as the "juicy main". Small integers auto coercing into floats is a nice gift to game devs. It's nice that game dev is acknowledged as one of the niches Zig can target as I believe it could really thrive there due to how easily it can integrate with C & C++. Or, rather, more easily than the alternatives.
slopinthebag 6mo ago
Have they said how many breaking changes requiring a rewrite Zig will be going through before it stabilises? Also I thought Zig doesn't have interfaces....how does the IO one work?
- pjmlp 6mo ago
  It has C style interfaces, meaning structs with function pointers. Which is basically how most device drivers in OSes that happen to be written in C, including UNIX flavours, work.
  - metaltyphoon 6mo ago
    We all know that OP wasn't asking about THAT kind of interface and more "please create vtables for me" style of interface
    - pjmlp 6mo ago
      That is too much compiler magic for Zig folks.
      - AndyKelley 6mo ago
        You know, I used to be annoyed by all your consistently shitty remarks in any zig related HN thread, but these days, it's refreshing to have an unpleasant interaction with a human. Sincerely, thanks for all your hand-written hatred.
        pjmlp 6mo ago
        It goes both ways, when I see remarks regarding other languages from Zig community folks, not from you directly. Modula-2 like safety is still better than C will ever be, though. Yeah, it will be human as far as I can take it, cheers.
        lmaoatyou 6mo ago
        [dead]
nesarkvechnep 6mo ago
Nice! I'm sad to see SegmentedList go. Also, I'm wondering if it's possible to use `recvmsg` and `sendmsg` backed by the new `Io` interface.
ksec 6mo ago
I/O, Linked, Incremental Compilation. Apart from 0.17 being a short release cycle. I wonder how many more releases before 1.0? Are we looking at 0.20, another one and half year of baking?
- baranul 6mo ago
  It's strange, because it has been over 10 years now. To get to 0.20, seems like it would be another 2 to 3 years. The weirdest thing is how Zig continuously gets a pass for being "almost there", for around 5 years now. An argument could be made that why it's taking so long is about the language's BDFL wanting the freedom to continually make breaking changes. As it is, they got another bewildering pass for sweeping 3,000 plus issues under the rug, with the move from GitHub to Codeberg.
  - mk12 6mo ago
    Programming languages take a long time to build. Zig is a more ambitious project than most. I see lots of progress in these release notes and I'm happy to "give a pass" for the fact that it's not finished. No one's been giving passes bewildering or otherwise for sweeping issues under the rug, because that didn't happen. The 0.16 release notes are linking to plenty of GitHub issues. If you have additional information to post on an issue then you can copy it to Codeberg: https://codeberg.org/ziglang/zig/issues/30027 https://codeberg.org/ziglang/zig/issues/30027
    - lerno 6mo ago
      I think Andrew should seriously think about decoupling the toolchain from the language to put focus on reaching stability there. As it is, we have the compiler with surrounding toolchain, the standard library and the language. The two former can keep evolving even language is fixed. Just being ambitious isn’t necessarily good. Look at Perl6.
  - ksec 6mo ago
    I honestly dont see it as an issue. At least not for now. You could have languages or software released as 1.0 at any time but they are not finished or ready for it. Arguably Crystal is a bit like that. Or you end up like NIM which they are on 3rd or 4th version already. And frankly speaking, a lot of people took to Wiki and said it has been 10 years, in reality Andrew only started working on it full time in 2018, and had a year off due to other personal issues, and then COVID hit. Together It is more like 6 years than 10.
gwenzek 6mo ago
https://ziglang.org/download/0.16.0/release-notes.html#Loop-Vectorization-Disabled-to-Work-Around-Regression https://ziglang.org/download/0.16.0/release-notes.html#Loop-... Seems like a big one! I wonder how it will impact real code performance
anttiharju 6mo ago
Really happy to see 0.16 come out. I did a really tiny contribution about zig cc supporting -exported_symbols_list, which together with the hack of filtering out -liconv makes for a very viable linux -> macOS Rust cross-compiler. There's a few caveats but those have been manageable so far. Absolutely in awe of Zig as a project.
jr-14 6mo ago
Seeing forbid runtime vector indexes seem unintuitive and hurt dev ergonomics...

166 points by ska80 6mo ago

sionisrecur 6mo ago

The "Juicy Main" looks like a very nice QoL feature. Gets rid of all the boilerplate for allocators and argv.

mihaelm 6mo ago
It's the dark horse of this release as CLI parsing can also be more easily built on top of it. There's a couple of proposals floating around now, so I hope we get something soon-ish (maybe in 0.18 since a short cyle is planned for 0.17).
- fredyr 6mo ago
  This sounds interesting to me - could you elaborate a little on what things are in those proposals?
  - mihaelm 6mo ago
    Sure, this is the issue tracking the work: https://codeberg.org/ziglang/zig/issues/30677 https://codeberg.org/ziglang/zig/issues/30677 The idea is to offer some kind of CLI parsing in the std. It says minimal, but the discussion also veers into some more advanced options. The discussion resulted in two PRs (that I know of): - Type-driven: https://codeberg.org/ziglang/zig/issues/30677 https://codeberg.org/ziglang/zig/issues/30677 @dotcarmen extracted it into a package (https://codeberg.org/dotcarmen/clip https://codeberg.org/dotcarmen/clip) so people could more easily try it out. - Composition-based: https://codeberg.org/ziglang/zig/pulls/31620 https://codeberg.org/ziglang/zig/pulls/31620 If you're familiar with Rust's clap, it's a bit like derive vs builder API. You can also see how each approach would look in practice if you inspect the diff for the "tools" directory on the PRs.
    - fredyr 6mo ago
      Thanks!
    - anttiharju 6mo ago
      clap's derive is so nice
portly 6mo ago
Do I get it right that this is everything you need for a typical CLI tool?
- nesarkvechnep 6mo ago
  You got that right.
  - portly 6mo ago
    That's clean.

_bohm 6mo ago

I've been waiting eagerly for this release ever since the new Io interface was announced. Pumped to start working on some new projects with this! Love this line from the release notes: > Lo! Lest one learn a lone release lesson, let proclaim: "cancelation" should seriously only be spelt thusly (single "l"). Let not evil, godless liars lead afoul.

xeubie 6mo ago

What a banger of a release. The new `Io` interface was a huge breaking change for my project, but I made the transition. Zig seems to be pulling the same trick it pulled with allocators: just make it an explicit value that you pass around. Explicit allocators felt obviously right in retrospect, and so far this feels obviously right too.

mihaelm 6mo ago
The approach feels like a natural extension of Zig's philosophy about explicitness around low-level operations (no hidden control flow, no hidden memory allocations, etc.). Your function can be blocking? Communicate that through the function signature! Very in style for the language.

mihaelm 6mo ago

Obviously, I/O as an interface is the headliner here, but there are lots of other goodies to pay attention to, such as the "juicy main". Small integers auto coercing into floats is a nice gift to game devs. It's nice that game dev is acknowledged as one of the niches Zig can target as I believe it could really thrive there due to how easily it can integrate with C & C++. Or, rather, more easily than the alternatives.

slopinthebag 6mo ago

Have they said how many breaking changes requiring a rewrite Zig will be going through before it stabilises? Also I thought Zig doesn't have interfaces....how does the IO one work?

pjmlp 6mo ago
It has C style interfaces, meaning structs with function pointers. Which is basically how most device drivers in OSes that happen to be written in C, including UNIX flavours, work.
- metaltyphoon 6mo ago
  We all know that OP wasn't asking about THAT kind of interface and more "please create vtables for me" style of interface
  - pjmlp 6mo ago
    That is too much compiler magic for Zig folks.
    - AndyKelley 6mo ago
      You know, I used to be annoyed by all your consistently shitty remarks in any zig related HN thread, but these days, it's refreshing to have an unpleasant interaction with a human. Sincerely, thanks for all your hand-written hatred.
      - pjmlp 6mo ago
        It goes both ways, when I see remarks regarding other languages from Zig community folks, not from you directly. Modula-2 like safety is still better than C will ever be, though. Yeah, it will be human as far as I can take it, cheers.
      - lmaoatyou 6mo ago
        [dead]

nesarkvechnep 6mo ago

Nice! I'm sad to see SegmentedList go. Also, I'm wondering if it's possible to use `recvmsg` and `sendmsg` backed by the new `Io` interface.

ksec 6mo ago

I/O, Linked, Incremental Compilation. Apart from 0.17 being a short release cycle. I wonder how many more releases before 1.0? Are we looking at 0.20, another one and half year of baking?

baranul 6mo ago
It's strange, because it has been over 10 years now. To get to 0.20, seems like it would be another 2 to 3 years. The weirdest thing is how Zig continuously gets a pass for being "almost there", for around 5 years now. An argument could be made that why it's taking so long is about the language's BDFL wanting the freedom to continually make breaking changes. As it is, they got another bewildering pass for sweeping 3,000 plus issues under the rug, with the move from GitHub to Codeberg.
- mk12 6mo ago
  Programming languages take a long time to build. Zig is a more ambitious project than most. I see lots of progress in these release notes and I'm happy to "give a pass" for the fact that it's not finished. No one's been giving passes bewildering or otherwise for sweeping issues under the rug, because that didn't happen. The 0.16 release notes are linking to plenty of GitHub issues. If you have additional information to post on an issue then you can copy it to Codeberg: https://codeberg.org/ziglang/zig/issues/30027 https://codeberg.org/ziglang/zig/issues/30027
  - lerno 6mo ago
    I think Andrew should seriously think about decoupling the toolchain from the language to put focus on reaching stability there. As it is, we have the compiler with surrounding toolchain, the standard library and the language. The two former can keep evolving even language is fixed. Just being ambitious isn’t necessarily good. Look at Perl6.
- ksec 6mo ago
  I honestly dont see it as an issue. At least not for now. You could have languages or software released as 1.0 at any time but they are not finished or ready for it. Arguably Crystal is a bit like that. Or you end up like NIM which they are on 3rd or 4th version already. And frankly speaking, a lot of people took to Wiki and said it has been 10 years, in reality Andrew only started working on it full time in 2018, and had a year off due to other personal issues, and then COVID hit. Together It is more like 6 years than 10.

gwenzek 6mo ago

https://ziglang.org/download/0.16.0/release-notes.html#Loop-Vectorization-Disabled-to-Work-Around-Regression https://ziglang.org/download/0.16.0/release-notes.html#Loop-... Seems like a big one! I wonder how it will impact real code performance

anttiharju 6mo ago

Really happy to see 0.16 come out. I did a really tiny contribution about zig cc supporting -exported_symbols_list, which together with the hack of filtering out -liconv makes for a very viable linux -> macOS Rust cross-compiler. There's a few caveats but those have been manageable so far. Absolutely in awe of Zig as a project.

jr-14 6mo ago

Seeing forbid runtime vector indexes seem unintuitive and hurt dev ergonomics...