Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type resolution redesign, with language changes to taste

ziglang.org

Post reply on HN
Print view View original

11–20 of 284 posts

Re: Type resolution redesign, with language changes to taste

#11

Post by AndyKelley »

throwaway17_17 wrote: post #7

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

Re: Type resolution redesign, with language changes to taste

#12

Post by Zambyte »

Cloudef wrote: post #3
h4ch1 wrote: 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 language itself does not change much, but the std does. It depends on individuals, but some people rely less on the std, some copy the old code that they still need. > Are there cases where packages you may use fall behind the language? Using third party packages is quite problematic yes. I don't recommend using them too much personally, unless you want to make more work for yourself.

Using third party packages has gotten a lot easier with the changes described in this devlog https://ziglang.org/devlog/2026/#2026-02-06

Re: Type resolution redesign, with language changes to taste

#13

Post by rowanG077 »

throwaway17_17 wrote: post #7

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…

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.

Re: Type resolution redesign, with language changes to taste

#14

Post by jibal »

throwaway17_17 wrote: post #7

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…

[flagged]

Re: Type resolution redesign, with language changes to taste

#15

Post by rtfeldman »

h4ch1 wrote: 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.

I maintain a ~250K LoC Zig compiler code base [0]. We've been through several breaking Zig releases (although the code base was much smaller for most of that time; Writergate is the main one we've had to deal with since the code base crossed the 100K LoC mark).

The language and stdlib changing hasn't been a major pain point in at least a year or two. There was some upgrade a couple of years ago that took us awhile to land (I think it might have been 0.12 -> 0.13 but I could be misremembering the exact version) but it's been smooth sailing for a long time now.

These days I'd put breaking releases in the "minor nuisance" category, and when people ask what I've liked and disliked about using Zig I rarely even remember to bring it up.

[0]: https://github.com/roc-lang/roc

Re: Type resolution redesign, with language changes to taste

#16

Post by throwaway27448 »

h4ch1 wrote: 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.

For those like me who have never heard of this software: Bun, some sort of package management service for javascript. https://en.wikipedia.org/wiki/Bun_(software)

Re: Type resolution redesign, with language changes to taste

#17

Post by boomlinde »

h4ch1 wrote: 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.

I stopped updating the compiler at 0.14 for three projects. Getting the correct toolchain is part of my (incremental) build process. I don't use any external Zig packages.

I think one of the more PITA changes necessary to get these projects to 0.15 is removing `usingnamespace`, which I've used to implement a kind of mixin. The projects are all a few thousand LOC and it shouldn't be that much trouble, but enough trouble that none of what I gain from upgrading currently justify doing it. I think that's fine.

Re: Type resolution redesign, with language changes to taste

#18

Post by beoberha »

throwaway27448 wrote: post #16
h4ch1 wrote: 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.

For those like me who have never heard of this software: Bun, some sort of package management service for javascript. https://en.wikipedia.org/wiki/Bun_(software)

Bun is a full fledged JavaScript runtime! Think node.js but fast

Re: Type resolution redesign, with language changes to taste

#19

Post by sgt »

latch wrote: post #10
quag wrote: post #8

Earlier quoted context omitted.

That .zig-cache seems massive to me. I keep mine on a tmpfs and remove it every time the tmpfs is full. Do you see any major problems when you remove your .zig-cache and start over?

Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.

Does Zig have incremental builds yet? Or is it 20 secs each time for your build.

Re: Type resolution redesign, with language changes to taste

#20

Post by throwaway27448 »

beoberha wrote: post #18
throwaway27448 wrote: post #16

Earlier quoted context omitted.

For those like me who have never heard of this software: Bun, some sort of package management service for javascript. https://en.wikipedia.org/wiki/Bun_(software)

Bun is a full fledged JavaScript runtime! Think node.js but fast

> Think node.js but fast

Color me extremely sceptical. Surely if you could make javascript fast google would have tried a decade ago....

Post reply on HN