Hacker News Reader

Comment by jfkebwjsbx | Hacker News Reader

C++ build times get high only if you start messing with the type system and ask for it to be recompiled every single time again and again.

Rust is slower overall, which is why people tend to complain. And if you start messing around like in C++, then you get even crazier times.

But in neither case it is a dealbreaker compared to other languages. Go proponents claim compilation speed is everything, which is suspicious. I do not need to run my code immediately if I am programming in C++ or Rust. And if I am really doing something that requires interactivity, I should be doing it another way, not recompiling every time...

View on HN

I think it's fairly naive to say build times get long "only if you mess with the type system" whatever that means. It's pretty easy to tank your compile/edit/debug cycle just by adding or removing things to a header file. Maybe modules will improve things.

I've worked in C++ code bases with just a few 100k loc where one starts architecting the software to avoid long compile times. Think about how insane that is, you choose to write and structure code differently as punishment for the sin of writing new code. Not to improve the software performance or add new features.

The worst example of this is the pimpl pattern. You make th explicit choice to trade off compile times to hide everything behind a pointer dereference that is almost guaranteed to be opaque to the compiler, even after LTO, so the only "inlining" you may see is from the branch predictor on a user's machine. That's bonkers!

>"only if you mess with the type system" whatever that means

I think they're talking about the STL.

Boost.

Of course compile times increase with code size, that is not what people are talking about when they say "X language compiles slowly". They are talking about time per code size.

Messing with the type system is using it for things you really should not in any reasonable project. For instance, some of the Boost libs with their overgeneralizations that 99% of users do not need.

Having a fast feedback loop helps with staying in the flow. Compile times need to be short for this.

What is "staying in the flow"?

Recompiling fast helps the most when learning to program, but not for actual applications with some complexity.

Many applications do not even have meaningful output by just running it, for instance they may take a long time to compute something meaningful.

it depends on the problem domain. when working on say a desktop app with graphical ui features it can be very useful to be able to change/experiment quickly.

with an n tier web application you wont often be able to do that anyway.

And this is why in its current state you wouldn't be seeing something like RustUI or Rust Playgrounds.

> What is "staying in the flow"?

Run the code (with some debug logging statements, very likely), find a small mistake, make a few characters worth of correction, press your IDE's keyboard shortcut for recompilation and re-running.

If the last step is slow you can lose momentum and motivation to iterate quickly on the problem at hand.

Sure it doesn't apply to a lot of projects, that's true. But it's not charitable to claim it only applies when learning.

That’s why you write unit and integration tests :) That’s how you get a fast feedback loop, instead of looking for it in compilation

Reply on news.ycombinator.com