You added to your comment while I was replying, so adding to what I said in the sibling reply:
> Being able to implement something does not mean that by implementing it a different way, it will certainly be faster.
Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more.
> You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works.
Yeah, actually I can. The claim is that LLVM is slow, so it's not Rust's fault. But LLVM isn't slow when compiling a language with nearly equivalent features, so that's a poor excuse. That's how engineering, logic, and accountability work. There is nothing in Rust which doesn't have an analog in C++, and C++ compilers aren't as slow as the Rust compiler.
> note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly."
You brought FastISel into the discussion. This is just another part of the shell game. Compare clang++, g++, and rustc with optimizations on or off.
> The claim is that LLVM is slow, so it's not Rust's fault.
I never claimed this. I claimed that there are a number of interlocking issues that make Rust compilation slow, and pointed out one that I haven’t seen a ton of discussion about before as an example of how it’s not a simple problem.
I also started this conversation by acknowledging one of the things that you said, which was that we generate a lot of LLVM-IR. That’s one that does get talked about a lot.
I don’t think we’re really gonna make any progress here so I’ll leave it at that.
No, the person I first replied to did. Then you jumped in and defended his position with your "yes and no" comment.
> I don’t think we’re really gonna make any progress here so I’ll leave it at that.
I agree. I always appreciate your friendliness and thoughtfulness, but I've never gotten you or anyone else on the Rust team to budge an inch on the problems with Rust. (which is a shame, because it's close to being a great language...)
It seems we’re in full agreement about the problems: compile times are too slow! Everyone acknowledges this. It seems like our disagreement is about the why.
> Being able to implement something does not mean that by implementing it a different way, it will certainly be faster.
Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more.
> You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works.
Yeah, actually I can. The claim is that LLVM is slow, so it's not Rust's fault. But LLVM isn't slow when compiling a language with nearly equivalent features, so that's a poor excuse. That's how engineering, logic, and accountability work. There is nothing in Rust which doesn't have an analog in C++, and C++ compilers aren't as slow as the Rust compiler.
> note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly."
You brought FastISel into the discussion. This is just another part of the shell game. Compare clang++, g++, and rustc with optimizations on or off.