One of the main reasons Zig was interesting to me was the fact that I could drop it in as an alternative to a C/C++ compiler. On Windows, my friends have mentioned how it is easier to install Zig as a C/C++ compiler than any other alternative.

If this proposal is accepted, I personally think Zig will drop to the popularity level of Hare or other extremely niche languages. Getting my colleagues to even try Zig out required me sending them articles about how Uber was using it in production. There is no way my colleagues would even have given it a second thought if it didn't have immediate value to their existing projects.

But I get where the proposal is coming from. LLVM compile times can seem awful, and there's lots of neat optimization tricks you could implement with your own byte code. And dealing with bugs in LLVM is basically a no-go, I've seen this happen in the Julia ecosystem as well.

If my recommendations are worth anything, I think Zig should

1. Use a custom bytecode for debug builds - fast build times, fast debug times etc 2. Use LLVM for release builds - fast runtime performance, slow release performance

If they can manage 1.) while still maintaining support for cross compiling C/C++ (just pass that part off to LLVM?) I think that might be the best of all worlds, with the tradeoff that there's additional backend code to maintain.