Live data from Hacker News

Type resolution redesign, with language changes to taste

ziglang.org

81–90 of 284 posts

Re: Type resolution redesign, with language changes to taste

#81

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 be…

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 w…

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.

Re: Type resolution redesign, with language changes to taste

#82
post #62

Earlier quoted context omitted.

Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit? I know, timelines not matching up, etc.

Definitely not. Rust gives you a tangible benefit in terms of correctness. It's such a valuable benefit that it outweighs the burden of incorporating a new language in the kernel, with all that comes with it.

Zig offers no such thing. It would be a like-for-like replacement of an unsafe old language with an unsafe new one. May even be a better language, but that's not enough reason to overcome the burden.

Re: Type resolution redesign, with language changes to taste

#83
post #62

Earlier quoted context omitted.

Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit? I know, timelines not matching up, etc.

And “if you enjoy C++/if you enjoy C” are gross oversimplifications.

Re: Type resolution redesign, with language changes to taste

#84
post #62

Earlier quoted context omitted.

Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit? I know, timelines not matching up, etc.

Memory safety by default in kernel sounds like a good idea :). However I don't think that C is being _replaced_ by Rust code, it's rather that more independent parts that don't need to deeply integrate with the existing C constructs can be written in a memory safe language, and IMO that's a fine tradeoff

Re: Type resolution redesign, with language changes to taste

#85
post #2

I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important. How's your experience with the constantly changing language? How're your update/rewrite cycles looking like? Are there cases where packages you may use fall behind the language? I know Bun's using zig to a degree of success, was wondering how the rest were doing.

The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.

> that has resulted in mindshare death as of 2026

I could make a bet that as of 2026 still more C++ projects are being started than Rust + Zig combined.

World is much more vast than ShowHN and GitHub would indicate.

Re: Type resolution redesign, with language changes to taste

#86

Earlier quoted context omitted.

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 w…

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…

I think rust calls them "zero sized types".

Re: Type resolution redesign, with language changes to taste

#87

Earlier quoted context omitted.

The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.

> that has resulted in mindshare death as of 2026 I could make a bet that as of 2026 still more C++ projects are being started than Rust + Zig combined. World is much more vast than ShowHN and GitHub would indicate.

Being started? I would take that bet.

Re: Type resolution redesign, with language changes to taste

#88
post #37

Earlier quoted context omitted.

The forever backwards compatible promise of C++ was a tremendous design mistake that has resulted in mindshare death as of 2026. It might suck to have to modify your code to continue to get it to work, but it’s the right long term approach.

There is a reason GCC, LLVM, CUDA, Metal, HPC,.. rely on C++ and will never rewrite to something else, including Zig.

Looking at LLVM build times I seriously believe that C would have been the better choice :/ (it wouldn't be a problem if LLVM wouldn't be the base for so many other projects)

Same for the Metal shading language. C++ adds exactly nothing useful to a shading language over a C dialect that's extended with vector and matrix math types (at least they didn't pick ObjC or Swift though).

Re: Type resolution redesign, with language changes to taste

#89
post #2

I would really like to hear from people using Zig in production/semi-serious applications; where software stability is important. How's your experience with the constantly changing language? How're your update/rewrite cycles looking like? Are there cases where packages you may use fall behind the language? I know Bun's using zig to a degree of success, was wondering how the rest were doing.

You can fix you code 10 times you will fix it.

Re: Type resolution redesign, with language changes to taste

#90
post #62

Earlier quoted context omitted.

I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024. Have you tried rust? how does it compared to zig? * just asking

Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

Comparing Rust to C++ feels strange to me.

It’s like people do it just because Zig is very comparable to C. So the more complex Rust must be like something else that is also complex, right? And C++ is complex, so…

But that is a bit nonsensical. Rust isn’t very close to C++ at all.

Post reply on HN