The most widely cited, and, quite frankly, most annoying issue with C++ these days are the difficult-to-read compilation error messages. But I will not get tired of stressing that ten minutes spent figuring out the types in a code snippet is an amazing time investment, especially given that the alternative is to spend at best one long and stressful day locating the issue and deploying the fix for a transient bug that is presently affecting production.

In RealtyShares the only two nontrivial pieces that require a C++ expect are schema evolution and generic data exporters. The former has to do with zero-downtime master flip while the underlying DB undergoes structural changes, and it sure _does_ need deep understanding of our templated type system to get _that_ code to build and run. And the latter _may_ need template metaprogramming, although in most practical cases a list of #define-s of included data tables and fields does the job just fine.

Needless to say, to pass the bus test our engineering team must have at least three C++ experts. I, for one, don't think it's uncommon these days.

* * *

Pros of node.js (and cons of C++):

1) Compilation takes time.

Yes. Being able to modify the code live is a huge win, which C++ does not have. I'll touch on this one a bit later.

2) A wide collection of packages.

Yes, npm is great. C++ is nowhere near that state of the art. Good news is: In a well-designed system there's hardly any need to perform node.js-level tasks in C++. That's what scripting languages are for, after all.

The only time I _almost_ had to write something that may require a Python or an node.js module was an internal dashboard page generation. After some thought, I've put dashboard_before.html and dashboard_after.html files into my C++ project, and had the backend output either a plain JQ-friendly JSON, or that very JSON squeezed in between those two files if Accept-Type of the request lists HTML. Last time I checked (just now), that's exactly the state in which this code is right now, fully functional in production, and used as the "UX" by several non-engineers.

* * *

Thus, the only real blocker is compilation and stating time. The frequency of development cycles, to be precise.

The compilation time itself is not an issue when the code is broken into compilation units (thanks Nathan!), especially since we moved to the gold linker (thanks Maxim!). The one-line change time in a CQS command is under fifteen seconds. The real challenge is: "interactively" deploying those changes to some test environment results in iterations that are still over an hour long.

We are eyeing the solution that enables dynamic on-the-fly adding of trusted just-built libraries into our test environments. It would improve the lives of the engineers working on those features dramatically. Unfortunately (or fortunately?) we never had a business need to dedicate sufficient effort to this task. Those few times when the situation warranted us to move faster, we always managed to push the C++-related changes through the door within just a few business days, leaving the remaining API-grade heavylifting to node.js or F#. Guess that's the curse of having enough C++ experts around. Or the "curse" of having good tests.

Or just the curse of a perfectionist architect in the world of modern engineering: every project becomes lo-pri the moment it's evident it does serve the business need "somewhat well". Such is life, might as well get used to.

* * *

To recap: a while ago I've made a prediction that C++, as long as it keeps becoming engineer-friendly, will be making a comeback, especially when it comes to developing backends in small-to-medium engineering organizations.

In the past two years I can confidently say we are solidly on track.

С++ folks, did you know inline constants exported into an .so are actually not inline at all?

This was quite a surprise for me today!

TL;DR: If you ::dlopen() two .so-s, like this:

// lib1.so
namespace nuance {
  inline int N = 42;
}
extern "C" int Get42() {
  return nuance::N;
}

// lib2.so
namespace nuance {
  inline int N = 101;
}
extern "C" int Get101WithANuance() {
  return nuance::N;
}

Then calling Get101WithANuance() will return ... drum rolls ... 42!

(Yes, order matters, etc., etc. The whole bouquet of issues you could possibly imagine, straight into your face. What a lovely footgun indeed!)

So much for yours truly sincerely believing that "inline is just a cleaner C++ way to #define symbols, with no symbols leaking wherever".

#LiveAndLearn

Ref: https://github.com/C5T/Current/pull/924