Comment by ComputerGuru
2 years ago
Approaching this from the lens of an interested observer with experience with other projects working on non-LLVM backends for their languages, I'm just struck by the amount of hubris in the linked proposal.
If it weren't for the author, I'd have dismissed the whole thing as a low-effort GitHub issue by a Zig newbie. The underestimation of the work involved, the backhanded dismissal of all the work that has gone into LLVM, the "obviously we can do it cheaper, faster, better" confidence/machoism that exudes from each sentence or claim.. I'm disappointed.
I've had nothing but respect for Andrew's work in the past so I'm going to extend him some grace and the benefit of the doubt and say that maybe it was just written in haste or on a whim without paying attention to how it came across. But it's not something that inspires me with confidence or lends me to give the proposal itself more of a chance.
I know nothing about LLVM backends, but it’s pretty common that libraries aiming to solve 100% of users problems eventually become unwieldy and slow compared to a more optimized alternative. Web Pack vs. esbuild is an example of this.
I get what you are trying to say but I have experience with both web and native tooling. This isn’t a valid comparison. Moreover, llvm isn’t one tool, it’s modular, fairly well-architectured, and can be compiled with or without any of a million different features.