4 ms·
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.
by rastignack 3y ago
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.
- j-pb 3y ago> 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.
- DannyBee 3y agoGo 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.
- TUSF 3y agoYeah, 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.