[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 TFA

With 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.

[munificent]

When someone's communication is casual and informal, without any context, you really can't distinguish between:

* The author is being flippant and not taking the situation seriously enough.

* The author is presuming a high-trust audience that knows that they have done all the due diligence and don't have to restate all of that.

In this case, it's a devlog (i.e. not a "marketing post") for a language that isn't at 1.0 yet. A certain amount of "if you're here, you probably have some background" is probably reasonable.

The post does link directly to the PR and the PR has a lot more context that clearly conveys the author knows what they are doing.

It is weird reading about (minor) breaking language changes sort of mentioned in passing. We're used to languages being extremely stable. But Zig isn't 1.0 yet. Andrew and friends certainly take user stability seriously, but you signed up for a certain amount of breakage if you pick the language today.

As someone who maintains a post-1.0 language, there really is a lot of value in breaking changes like this. It's good to fix things while your userbase is small. It's maddening to have to live with obvious warts in the language simply because the userbase got too big for you to feasibly fix it, even when all the users wish you could fix it too. (Witness: The broken precedence of bitwise operators in C.)

It's better for all future users to get the language as clean and solid as you can while it's still malleable.

[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/3257

Later, Matthew Lugg made a follow-up proposal, which was discussed both publicly and in ZSF core team meetings. https://github.com/ziglang/zig/issues/15909

He 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 motive to enshittify.

[1]: https://ziglang.org/documentation/master/#Zen

It'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.

[tialaramex]

Where does the name "zero type" come from? In type theory this is called an "empty" type because the set of values of this type is empty and I couldn't find (though I have no idea where to start) mention of it as a "zero" type.

This stuff is foundational and so it's certainly a priority to get it right (which C++ didn't and will be paying for until it finally collapses under its own weight) but it's easier to follow as an outsider when people use conventional terminology.

[Cloudef]

I think rust calls them "zero sized types".

[tialaramex]

The ZSTs are unit types. They have one value, which we usually write as just the type name, so e.g.

    struct Goose;

    let x = Goose; // The variable x has type Goose, but also value Goose, the only value of that type

The choice to underscore that Rust's unit types have size zero is to contrast with languages like C or C++ where these types, which don't need representing, must nevertheless take up a whole byte of storage and it's just wasted.

But what we're talking about here are empty types. In Rust we'd write this:

    enum Donkey {}

    // We can't make any variables with the Donkey type, because there are no values of this type and a variable needs a value

[mk12]

No, that’s a different thing. “noreturn” is like Rust’s “never” type (spelled as an exclamation mark, !). Also known as an “uninhabited type” in programming language theory.

[tialaramex]

Note that Rust's ! isn't stabilized, however you can (in stable Rust, today) make your own empty/ uninhabited types, yours just isn't "the" canonical empty type for the language, and so the type arithmetic won't necessarily see that it's the same thing in some cases if that matters.

Rust's core::convert::Infallible is such a type, representing in that case the error type for conversions which have no errors. For example, we can try to convert most numeric types into a 16-bit unsigned type, and obviously most of them can fail because your value was too big or negative or whatever. u16 however obviously never fails, the conversion is a no-op, nevertheless it would be stupid if we can't write generic code to convert it - so of course we can, and if we wrote generic error handling code, that code is dead for the u16 case, we can't fail, the use of empty types here justifies the compiler saying OK, that code is dead, don't emit it. Likewise converting u8 to u16 can't fail - although it's slightly more than a no-op in some sense - and so again the error handling is dead code.

[Cloudef]

I see. I can not give more insightful answer here then. From personal experience, I've noticed with 0.16 with the std.Io async stuff that you cannot do:

   io.concurrent(foo, .{});

where foo's return type is `error{foobar}!noreturn`, because the compiler crashes when it tries to use that type as a std.Io.Future(T)'s struct field. Might be related or not.

[mlugg]

It is indeed (somewhat) related, and in fact that was fixed by this PR: https://github.com/ziglang/zig/issues/25771

[throwaway17_17]

Thanks for the reply Andrew, I certainly did not mean to imply any issues with trustworthiness for Zig users or prospective adopters. Also, I absolutely did not intend to imply any negatives toward Zog’s evolution or this particular development on the compiler’s internals.

I enjoy all of the process and implementation content, i.e. videos, podcast, and blogs that yourself and contributors have provided through various platforms over the years. I made a comment from a relatively u informed place and it seems to have been taken as a negative remark on Zig or the language and compiler’s development. Apologies if it was seen that way yourself or other contributors.

As for Matthew, the work both planning and implementing these changes was clearly a large undertaking and I certainly applaud that and hope no one thought otherwise.

[bro45x]

Zog? What the hell man.

[norman784]

I don't use Zig (is not a language for me), but I like to read/watch about it, when you or others talk about the language design and the reasons behind the changes.

Thanks for your and the Zig team work.

[hitekker]

> Zig the language from experimental territory a large degree towards being formally specified

Great to hear; I look forward to reading the language spec one day.

[bro45x]

You're the man Kelley, don't let the doomers get to you

[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.