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

21–30 of 284 posts

Re: Type resolution redesign, with language changes to taste

#21

Post by h4ch1 »

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.

But why is it so big in the first place?

I was searching around for causes and came across the following issues: https://github.com/ziglang/zig/issues/15358 which was moved to https://codeberg.org/ziglang/zig/issues/30193

The following quotes stand out

> zig's caching system is designed explicitly so that garbage collection could happen in one process simultaneously while the cache is being used by another process.

> I just ran WizTree to find out why my disk was full, and the zig cache for one project alone was like 140 GB.

> not only the .zig-cache directory in my projects, but the global zig cache directory which is caching various dependencies: I'm finding each week I have to clear both caches to prevent run-away disk space

Like what's going on? This doesn't seem normal at all. I also read somewhere that zig stores every version of your binary as well? Can you shed some light on why it works like this in zigland?

Re: Type resolution redesign, with language changes to taste

#22

Post by Cloudef »

h4ch1 wrote: post #21
latch wrote: post #10

Earlier quoted context omitted.

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

But why is it so big in the first place? I was searching around for causes and came across the following issues: https://github.com/ziglang/zig/issues/15358 which was moved to https://codeberg.org/ziglang/zig/issues/30193 The following quotes stand out > zig's caching system is designed explicitly so that garbage collection could happen in one process simultaneously while the cache is being used by another process. >…

AFAIK garbage collection is basically not implemented yet. I myself do `ZIG_LOCAL_CACHE_DIR=~/.cache/zig` so I only have to nuke single directory whenever I feel like it.

Re: Type resolution redesign, with language changes to taste

#23

Post by latch »

sgt wrote: post #19
latch wrote: post #10

Earlier quoted context omitted.

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.

20 seconds each time. Last time I tried to enable incremental build, it wasn't working for us. It was a while ago, but I think it had to do with something in our v8 bridge.

Re: Type resolution redesign, with language changes to taste

#24

Post by leonflexo »

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

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.

Re: Type resolution redesign, with language changes to taste

#25

Post by scuff3d »

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.

Mitchell Hashimoto (developer of Ghostty) talks about Zig a lot. Ghostty is written in it, and he seems to love it. The churn doesn't seem to bother him at all.

I asked him about in a thread a while back: https://news.ycombinator.com/item?id=47206009#47209313

The makers of TigerBeatle also rave about how good Zig is.

Re: Type resolution redesign, with language changes to taste

#26

Post by sgt »

latch wrote: post #23
sgt wrote: post #19

Earlier quoted context omitted.

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

20 seconds each time. Last time I tried to enable incremental build, it wasn't working for us. It was a while ago, but I think it had to do with something in our v8 bridge.

I have heard that from other Zig devs too. Must get a bit annoying as the project grows. But I guess it will be supported sooner or later.

Re: Type resolution redesign, with language changes to taste

#27

Post by nickysielicki »

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.

Re: Type resolution redesign, with language changes to taste

#28

Post by fouronnes3 »

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.

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.

Re: Type resolution redesign, with language changes to taste

#29

Post by saghm »

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]

They literally ended the comment by asking. I don't get why you're criticizing them for providing context that they're not an expert. You're literally distracting from the comment you're telling them has useful information on it, but in a weirdly aggressive way.

Re: Type resolution redesign, with language changes to taste

#30

Post by throwaway27448 »

leonflexo wrote: post #24
throwaway27448 wrote: post #20

Earlier quoted context omitted.

> Think node.js but fast Color me extremely sceptical. Surely if you could make javascript fast google would have tried a decade ago....

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.

Post reply on HN