Hacker News Reader

Comment by civility | Hacker News Reader

If Rust didn't have good runtime performance, it wouldn't be worth looking at over SML, Ocaml, or Haskell.

> So let's get back to the performance of the code generated by the Rust compiler, shall we?

"Shall we" just stick our heads in the sand too? No, you don't fix problems by ignoring them or pretending they aren't a problem. Slow compilation speed is a problem if you care about developer productivity and quality of life.

View on HN

Slow compilation speed is never a problem, I doubt anyone besides you cares about it. What is important is whether it generates fast code. Taking a long time to compile is fine if I get very fast code. I'm not going to be compiling code anywhere near as many times as I'm going to be running it.

You really think it's just me? Take care.

I do. Computers for most people are tools to perform final work faster, not a purpose unto itself which is all about programmer's convenience. A programmer's job is to be as uncomfortable and to suffer as much as possible so that the users could suffer as little as possible or not at all. This "developer convenience" attitude should be reproached or even financially penalized, so that such prima donnas finally come down to earth and start taking responsibility for their (shitty) software.

Compilers don't have to be slow to generate good code (at least not as slow as Rust). If you prefer them slow, you're just choosing to be ineffective like some idiotic martyr. Suffering for it's own sake is just stupid.

I don't care about that, could not care less: I just do make -j 96 and go do something else. The only thing that matters is very fast code. Back-end optimizers cost CPU cycles, there's no way around that. Expecting fast compilation times when iropt and lto have to do their thing is incredibly naive. How can anyone in this day and age be so naive?

Reply on news.ycombinator.com