To me the question is moot if the problem is llvm. I don't know if that's the case or not.

Modern tools require modern hardware. If the problem is that the target constraints don't allow modern tools to be used, the problem is the constraints and not the tools.

But maybe I just don't understand their stance here.

Depending on what you are working on / with, you may not be able to choose your constraints.

Constraints that you cannot change can certainly dictate what tools you have to choose from.

No, I don't think so. If LLVM is at fault then the issue is definitely not inherent to Rust the language or Rust the development culture.

Your code is what it depends on. If you are picking dependencies with no concern for the overhead they introduce, well, it says everything it needs to say: you value that dependency over the associated overhead it introduces.

Asking an OS to adopt those same preferences, without any appreciation for their needs or preferences is pretty rude and arrogant.

A better solution would be to ask “what would it take, because I’d like to understand your needs”. Maybe then Theo could help you understand their constraints. Trying to argue with him that he needs something he clearly doesn’t isn’t very nice and won’t get a nice response if you push it too far.

You are ultimately responsible for your dependencies. No program is innocent of its dependency graph.

Interesting point.

Does anyone know how much memory is needed to compile llvm+clang? GCC?

That varies widely on your linker and how many threads you use. I have compiled LLVM on systems with 4 GB of RAM, though; but have been forced to fall back on single-threaded compilation.

IDK about compiling llvm/clang, but using clang/llvm needs far less memory than gcc. I've used clang in machines with less than 256mb of RAM.