Hacker News Reader

Comment by naasking | Hacker News Reader

Bizarre that he thinks a language or compiler is doomed unless it can compile itself on each platform it supports. Microcontrollers and cross-compilation wouldn't exist if that were the case.

View on HN

I think it was more the implication that requiring more than 2GB of RAM to compile itself was an indication of its profligate resource usage.

How much of that is Indicative of rustc vs llvm? The latter isn't exact a lightweight piece of software.

Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?

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.

Interesting point.

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

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.

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.

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.

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.

It seems like a number of *BSD projects are generally in favor of llvm and clang, in part because they dislike GNU/FSF.

I know OpenBSD supports some more esoteric hardware that LLVM probably will not target, however.

That doesn’t seem like an especially strong argument since computing is full of time/space trade-offs and 2GB of RAM hasn’t been a significant amount for over a decade at this point (X86-64 only goes back to 2003 but it was a latecomer following Intel’s epic failure to deliver Itanium). Things like whole program optimization seem like a reasonable trade off for <$20 worth of RAM.

Well OpenBSD has this "dumb" rule that snapshots/releases are never cross compiled and be done on real hardware. So it's pretty much a rule that every hardware platform has to be self hosting.

Microcontrollers are the exception, but then they don't run a full blown OpenBSD stack anyways.

Reply on news.ycombinator.com