> C++ builds can be made bearable if you don't go crazy with template meta-programming, do forward declarations, only expose actually public data on the headers, instantiate most use templates.

Exactly. E.g. QT based applications (which rely on object orientation, inheritance and virtual methods) compile reasonably fast. However the template oriented style (e.g. found in boost libraries) can increase compile times A LOT. I had more than factor 10 for one of my libraries that I ported from having boost as a dependency to QT. Although the template oriented style might really work faster at runtime, because there's less need for virtual function calls and other indirections.

I suspect with 10+ year old hardware he will not be on Windows.

Well, the OP is a pro-Rust topic, so yeah.

As I said on the top-level comment that opened this thread, I'm tentatively considering Rust. I'd love for it to take off and become a serious and reliable contender. I have a tendency to be conservative and cautious (generally), so I'm seeing how things pan out.

I guess it depends on what you're used to. Each time I switch from C to C++, compile times take some adjusting.

If you're not careful about how you organise your C++ code (be careful what you put in headers, don't go crazy with templates), compiling can get really slow, even for relatively small projects.

Just #include <iostream> and the compiler needs to process 37,799(!) lines and more than a MB of data:

  echo '#include <iostream>' | g++ -E  -x c++ - | wc
     37799  104779 1280834

To contrast in C:

  echo '#include <stdio.h>' | gcc -E  -x c - | wc
       456    1638   20880

Comparing the compile times of PostgreSQL (C, minutes on an old laptop) and MySQL (C++, 30+ minutes) is also instructive.

Maybe when modules are finally introduced, things will improve.

I'd edit this into the original comment if I could; here seems to be a good spot to put it.

I think I should add a bit of context about what I mean by slow compile times: I feel comfortable if I can hit CTRL+S* and have my code rerun or restart within about half a second. At one second, it should either be executing or have output something and finished, and if it takes more than about 10 seconds to get to whatever point I'm prototyping or making a decision on, I get jittery.

It's partly because I have a ridiculously short feedback loop, but also because I am (for some reason) sensitive to interactivity latency and I prioritize responsiveness extremely highly. So long compile times tend to lean on those buttons and make me uncomfortable.

With this in mind, the only C++ experience I've had yet was doing some modifications to the Dillo web browser, which was the main web browser I was running on the 800MHz AMD Duron box I used between 2012-2014 (the same one I described in https://news.ycombinator.com/item?id=13344332).

It was a lot of fun - I modified the tab bar so tabs could be dragged around, moved between windows, etc :D - but the compile times were around 3 seconds! This was just for the test harness I built which had an absolute minimum of code in it; I was also using GCC precompiled headers for literally everything (my prototype code was a ~300 line .cpp file, no headers or anything). This was a really big adjustment for someone used to tcc (~10ms compile time) or gcc (~300ms compile time) who felt that gcc took juuuust a bit too long to do its thing.

I've seen C and C++ code compile on friends' i3 boxes (haven't seen what an i7 can do yet) and been amazed. I think when I have a machine like that I'll probably be able to seriously get into the language. (I actually have an i3 here but it had a memory failure several months ago, hopefully I can get some new DIMMs for it soon and see if the motherboard actually still works.)

--

* About ^S - I'm yet to play with Emacs which I understand has two keystrokes to save files; I mostly use Vim because it's installed everywhere. I far prefer ^S over ESC (Press)Shift ; (Release)Shift w Return i/a.

Its all relative.