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

41–50 of 284 posts

Re: Type resolution redesign, with language changes to taste

#41

Post by leonflexo »

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.

I think Bun helps with the memory pressure, granted this is relative to V8. I'd pushback on the certainty with the reality that TS provides a significant drop in entropy while benefiting from what is a sweet spot between massive corpus size and low barrier for typical problem/use-case complexity. You'll never have the fastest product with JS, but you will always have good speed to market and be able to move quickly.

Re: Type resolution redesign, with language changes to taste

#42

Post by quotemstr »

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.

Hilariously, they broke this compatibility. std::auto_ptr was an abomination, but removing it from the language was needless and undermined the long term stability that differentiates C++ from upstarts.

Re: Type resolution redesign, with language changes to taste

#43

Post by dtj1123 »

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.

Claude CLI is based on bun. The dependency is so complete that Bun have now joined Anthropic.

Re: Type resolution redesign, with language changes to taste

#44

Post by throwaway27448 »

dtj1123 wrote: post #43
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.

Claude CLI is based on bun. The dependency is so complete that Bun have now joined Anthropic.

Claude CLI is not exactly a reference of usable software

Re: Type resolution redesign, with language changes to taste

#45

Post by throwaway27448 »

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.

I can't vouch for this behavior but obviously you can have a better serverless experience than writing lisp with the shittiest syntax invented by man

Re: Type resolution redesign, with language changes to taste

#46

Post by munificent »

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.

The biggest problem with C++ is that while everyone agrees there is a great language hiding in it, everyone also has a remarkably different idea of what that great language actually is.

Re: Type resolution redesign, with language changes to taste

#47

Post by the_duke »

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.

Rust has managed just fine to remain mostly backwards compatible since 1.0 , while still allowing for evolution of the language through editions.

This puts much more work on the compiler development side, but it's a great boon for the ecosystem.

To be fair, zig is pre 1.0, but Zig is also already 8 years old. Rust turned 1.0 at ~ 5 years, I think.

Re: Type resolution redesign, with language changes to taste

#48

Post by rererereferred »

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

The actual JS code is in the same ballpark as nodejs. They get fast by specializing to each platform's fastest APIs instead of using generic ones, reimplementing JS libraries in Zig (for example npm or jest) and using faster libraries (for example they use the oniguruma regex engine). Also you don't need an extra transpiling step when using TypeScript.

Re: Type resolution redesign, with language changes to taste

#49

Post by sidkshatriya »

sidkshatriya wrote: post #34
latch wrote: post #4

Earlier quoted context omitted.

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.

I don't know why I was downvoted here. One day, I was experiencing weird compilation errors. Clearing the `ccache` C/C++ compiler cache helped get past the problem. Yes, I could have investigated in detail what was the issue and if ccache had a bug but sometimes you don't have the luxury of investigating everything your toolchain throws at you.

Re: Type resolution redesign, with language changes to taste

#50

Post by munificent »

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…

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.

Post reply on HN