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

31–40 of 284 posts

Re: Type resolution redesign, with language changes to taste

#31

Post by hitekker »

AndyKelley wrote: post #11
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 w…

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

Re: Type resolution redesign, with language changes to taste

#32

Post by undeveloper »

throwaway27448 wrote: post #20
beoberha wrote: post #18

Earlier quoted context omitted.

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

they have, v8 is a pretty fast engine and an engineering marvel. bun is faster at cost of having worse jit and less correctness

Re: Type resolution redesign, with language changes to taste

#33

Post by 8n4vidtmkvmk »

jibal wrote: post #14
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]

This seems unnecessarily hostile. They are asking. Here.

Re: Type resolution redesign, with language changes to taste

#34

Post by sidkshatriya »

latch wrote: post #4
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.

Zig 0.15 is pretty stable. The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path. I've yet to find exactly why this [only sometimes] causes such a crash, but they're a real pain to figure out over a large changeset. `zig ast-check` sometimes catches the error, else Claude's pretty good at spotting where I accidentally re-used a variable name (again, 90% o…

> The biggest issue I face daily are silent compiler errors (SIGBUS) for trivial things, e.g. a typo in an import path.

I don't use zig. My experience has been that caches themselves are sources of bugs (not talking about zig only, but in general). Clearing all relevant caches occasionally is useful when you're experiencing weird bugs.

Re: Type resolution redesign, with language changes to taste

#35

Post by messe »

throwaway27448 wrote: post #30
leonflexo wrote: post #24

Earlier quoted context omitted.

Bun uses JSC (JavaScriptCore) instead of V8. From what I understand, whereas Node/V8 has a higher tier 4 "top speed", JSC is more optimized for memory and is faster to tier up early/less overhead. Good for serverless. Great for agents -> Anthropic purchase.

> Good for serverless. Great for agents -> Anthropic purchase. Surely nobody would use javascript for either yea? The weaknesses of the language are amplified in constrained environments: low certainty, high memory pressure, high startup costs.

> Surely nobody would use javascript for either yea?

It's probably the most popular language for serverless.

Re: Type resolution redesign, with language changes to taste

#37

Post by pjmlp »

nickysielicki wrote: post #27
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 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.

Re: Type resolution redesign, with language changes to taste

#38

Post by pjmlp »

fouronnes3 wrote: post #28
nickysielicki wrote: post #27

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.

Mindshare death is a very large overstatement given the massive amount of legacy C++ out there that will be maintained by poor souls for year to come. But you are right, there used to be a great language hiding within C++ if the committee ever dared to break backwards compat. But even if they did it now it would be too late and they'd just end up with a worse Rust or Zig.

As proven a few times, it doesn't matter if committee decides to break something if compiler vendors aren't on board with what is being broken.

There is still this disconnection on how languages under ISO process work in the industry.

Re: Type resolution redesign, with language changes to taste

#39

Post by sidkshatriya »

I am impressed by the achievements of the Zig team. I use the ghostty terminal emulator regularly -- it is built in Zig and it is super stable. It is a fantastic piece of software.

This makes me feel that the underlying technology behind Zig is solid.

But I prefer Rust over Zig. The main difference is Rust chooses a "closed world" model while Zig chooses an "open world" model: in Rust, you must explicitly implement a trait while in Zig as long as the shape fits, or the `.` on a structure member exists (for whichever type you pass in), it will work (I don't use Zig so pardon hand wavy description).

This gives Zig very powerful meta programming abilities but is a pain because you don't know what kind of type "shapes" will be used in a particular piece of code. Zig is similar to C++ templates in some respects.

This has a ripple effect everywhere. Rust generated documentation is very rich and explicit about what functions a structure supports (as each trait is explicitly enrolled and implemented). In Zig the dynamic nature of the code becomes a problem with autocomplete, documentation, LSP support, ...

Re: Type resolution redesign, with language changes to taste

#40

Post by pjmlp »

messe wrote: post #35
throwaway27448 wrote: post #30

Earlier quoted context omitted.

> Good for serverless. Great for agents -> Anthropic purchase. Surely nobody would use javascript for either yea? The weaknesses of the language are amplified in constrained environments: low certainty, high memory pressure, high startup costs.

> Surely nobody would use javascript for either yea? It's probably the most popular language for serverless.

Only because the likes of Vercel and Netlify barely offer anything else on their free tiers.

When people go AWS, Azure, GCP,... other languages take the reigns.

Post reply on HN