Comment by j-pb | Hacker News Reader

Comment by j-pb | Hacker News Reader

Parent Full thread

Priorities. The team is too focused on global maxima, speed and reinventing compiler design at the cost of a reference implementation that's fundamentally broken, and too complex to fix.

This results in miscompilations, broken buildins, features added that are then ripped out again.

I think fast iterations and experimental stuff are ok if you have a stable core. I.e. I don't mind if zig decides to change its for loop syntax after 5 years, so long as there is a simpler stable construct like `loop { break; }` that people that use the language in production and library maintainers can use.

You need a certain critical mass for a language to be self sustaining, and that requires people to actually use your stuff, which in turn requires at least some stability guarantees for some subset of the language.

Zig's response to that is "I'm just my inventors toy yet, but it will be grand when version 1.0 hits in 10-50 years."

The fact that they now want to replace LLVM with their own backend makes me think that even 50 years would be optimistic.

I think the plan is to avoid linking with llvm, not getting rid of llvm altogether.

To be fair go has never used llvm and was delivered in less that 50 years.

> To be fair go has never used llvm and was delivered in less that 50 years.

And if Zig was a google project instead of a 3 person show, I'd be far more inclined to believe that they can pull this off.

But as previously said, the current style of development makes it hard to attract contributors and more importantly funding.

Go did not have the goal of the best possible performance, it was targeting good performance with amazing compile times. It still targets this. It was also developed by some of the most productive geniuses in the world (disclaimer: the go team used to report up through me)

Getting to 70 percent of llvm will be relatively easy for zig and like all others, they will congratulate themselves and pretend it validates their choice. They will then discover the other 30 percent happens 0.1% at a time, because there are no silver bullets. This will take them 10+ years because it always does.

Yeah, LLVM is here to stay for Zig. The plan is to have a custom backend for fast Debug builds for use during development, while emitting LLVM bitcode for release builds that can then be fed to LLVM.

Not linking to LLVM would also make the barrier to entry on contributing to Zig itself lower, because now you can just compile Zig with Zig, and not worry about other dependencies.

Reply on news.ycombinator.com