Zig 0.16.0 Release Notes

151

sska80 about 24 hours ago 33 commentsRead Article on ziglang.org

FR version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

80% Positive

Analyzed from 739 words in the discussion.

Discussion (33 Comments)Read Original on HackerNews

mihaelm•about 23 hours 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.

anttiharju•about 13 hours 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.

xeubie•about 23 hours 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•about 22 hours 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.

sionisrecur•about 23 hours ago

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

mihaelm•about 23 hours 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•about 22 hours ago

This sounds interesting to me - could you elaborate a little on what things are in those proposals?

mihaelm•about 21 hours ago

Sure, this is the issue tracking the work: 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

@dotcarmen extracted it into a package (https://codeberg.org/dotcarmen/clip) so people could more easily try it out.

- Composition-based: 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.

portly•about 21 hours ago

Do I get it right that this is everything you need for a typical CLI tool?

nesarkvechnep•about 20 hours ago

You got that right.

portly•about 20 hours ago

That's clean.

nesarkvechnep•about 20 hours 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.

gwenzek•about 15 hours ago

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

ksec•about 17 hours 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?

_bohm•about 23 hours 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.

slopinthebag•about 21 hours 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?

badtuple•about 20 hours ago

Interfaces can still be expressed using vtables. You just have to write the vtable yourself rather than have the language do it for you.

Also, Zig's tagged unions (enums with payloads in Rust) are really ergonomic and often what you want instead of interfaces. Alot of languages that use interfaces simply don't expose a good way of doing it so everyone reaches for interfaces by default. But if you don't need an actual interface then this way you don't even have to pay the cost of runtime dynamic dispatch.

redrobein•about 16 hours ago

Are there any plans to add syntax sugar for interacting with vtables?

lenkite•about 9 hours ago

Wish we could bribe Andrew Kelley to add a built-in for this. There are only a couple of regular ways that everyone creates these vtables. Might as well just standardize it.

metaltyphoon•about 14 hours ago

Sadly no, as fas as I'm aware. I can't think of creating vtables manually every time I need to create interfaces, I guess Zig is not for me.

pjmlp•about 20 hours 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•about 14 hours 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•about 11 hours ago

That is too much compiler magic for Zig folks.

slopinthebag•about 12 hours ago

That's a hack, not an interface lol

spiffyk•about 6 hours ago

How is it a hack? I mean, you may not like the fact that Zig does not provide syntax sugar for interfaces, but how exactly do you think they are implemented in languages that do?

pjmlp•about 11 hours ago

As plenty of other things in an "everything is explicit" language, whose goal is to be a safer C and nothing else.

The "module" system is another hack.

zamadatix•about 14 hours ago

If they knew what all of the 0.x breaking changes were going to be ahead of time they wouldn't need to be trying out different choices to see how well they really pan out!