I didn’t compare HEADs because I’m on my phone, but found reports that in 2019, LLVM was 7 million LOC, and gcc was 15. Both are C++ compiler projects. Why the double standard?
I also don’t know why re-writing an entire project and creating a compiler for it is somehow easier than writing an LLVM backend.
What double standard? I wouldn't recommend a language tie itself to GCC any more than I would recommend LLVM. The point is that the Rust compiler catalog is unhealthily small, and that introduces problems like this one.
To your other point, writing an LLVM backend is one thing. Getting it upstreamed is another, and maintaining it is another still. Then you have to navigate the politics of two foundations, both of whose boards of directors are basically the Who's Who of competing interests. I've watched more than one project fail to navigate those waters.
Anyway, the cryptography package going from python + c to python + C + C++ + Rust is a cambrian explosion of build time complexity, and in my work we found it simpler to just get rid of the python and the cryptography package, so it's mostly academic to me.
> I wouldn't recommend a language tie itself to GCC
Okay! I misunderstood you then, sorry. I think one of the hardest parts about this conversation is that there are so many different people with various, but overlapping, opinions. A lot of folks do think this way, and I thought that's what you were saying. My bad.
> Getting it upstreamed is another
You do not need it to be upstreamed in order to build Rust, we build with our own modified LLVM by default, so using it is quite easy.
The question has probably been asked a thousand times before, but wouldn't all those bootstrapping problems for niche platforms be solved if Rust had a C backend? Are there technical issues which would prevent compiling LLVM bytecode to a C blob, similar to what wasm2c does for WASM bytecode?
I think, like majewsky says, it is a bit more complicated than it may initially seem. However, even if we assume that it is trivial, there's other problems. Sure, maybe it would. But who is going to do that work? We're an open source project. Effort is not fungible. On some level, we can only get stuff done when there's a sufficient need for it, and while there have been some folks talking about this in the last week or so, historically, it just hasn't been a massive issue. If it is a massive problem for someone, they should solve it! The Rust project's stance has been open to new platforms, and will continue to be so. But we need experts in those areas to help us help themselves.
Having a C backend does not solve the hard issues. Because of undefined behavior in the C specification, sometimes there just is no way to write down a particular expression in a portable manner in C without treading through undefined territory. This may not be as big of a deal for boring application code, but we're talking about cryptographic code here, which needs to work hard to avoid memory corruption, integer overflows, timing side channels, etc.
I'd imagine the generated code could be hardened similar to the code generated by clang ASAN, UBSAN and TSAN, and also wouldn't generate code that depends on undefined behaviour in the first place. Or you could do a little detour through WASM:
I also don’t know why re-writing an entire project and creating a compiler for it is somehow easier than writing an LLVM backend.