We use a very conservative subset of C++, almost like C with inheritance. We barely even use templates. We try to avoid allocating on the heap. The code is mostly imperative.
Since 2011, a lot of new language features have been introduced. The ones we use are things like smart pointers (that improve lifetime management) and some tweaks for better type safety.
It is said that moden C++ enables a functional programming style. I have never actually seen anybody code that way (it would be hell to write and worse to read) but that could just be the niche I'm in.
What is undeniable is that C++ is so complex and has so many features that you have to choose a subset of the language to enforce a consistent style.
Also a lot of the STL (standard library functions) are deprecated in one way or another, which is a real minefield.
C also has dialects.
This kind of thing doesn't happen when I interview in other languages.
First languages with run-times and dynamic types, and more recently lower levels of abstraction (Go, Rust).
It was FOSS with its set of coding guidelines, that gave C a new wind.
Languages with runtimes and dynamic types go all the way back to Lisp and Smalltalk.
Java was the 800lb gorilla though, wasn't it? Because it promised portability.
Why did Smalltalk not take off?
Write Once Runs Everyone has been the promise of several bytecode formats since UNCOL in 1958, with UCSD Pascal being the most famous one until Java came to be.
Smalltalk was already taking off when Java came to be, it had a role similar to .NET on Windows, on OS/2, with SOM (OS/2's version of COM), doing C, C++ and Smalltalk.
All IBM Visual Age IDEs were written in Smalltalk, however it was exactly IBM alongside Oracle that were the very first to jump onboard to the Java ship.
Thus one day of the other, Smalltalk was out, and Java in.
Eclipse started as a rewrite from Visual Age into Java, and many of the Java early frameworks were ports from Smalltalk.
Also note that while Java has a C++ like syntax, its execution model is closer to Smalltalk and Objective-C, thus why it was such a great fit for Sun, acquiring StrongTalk and re-purposing the JIT compiler into Hotspot.
== Not standardized. Language vendors used proprietary code to lock-in customers and that fragmented the skills base. Skilled Smalltalk-A programmers were not-so-skilled with Smalltalk-B.
== Not free as in beer.
I only know them from openMP (more of a Fortran person)… without much thought my gut says that it’d be possible to implement an atomic operation with a mutex, but sort of defeating the purpose. An atomic operation is mostly expected (intended? hoped?) to be backed by some hardware atomic instructions anyway, right?
I had been using a truly awful stdlib on an embedded platform whose implementers saw that freedom as a license to implement all atomics with mutexes. I assume it was because they couldn't be bothered to write new implementations for every platform they supported, so they'd write the basic primitives and got the rest of the implementation "for free". This isn't even close to the dumbest decision they made.
Obviously that wasn't acceptable for any real use, so I wrote up a better implementation, sent it to the vendor as a patch to save their other poor customers the effort, and used it as a one line example in a larger list on my resume that the interviewer seized on. It's not uncommon for a FAANG interview to be adversarial like that.
[0] https://en.cppreference.com/cpp/atomic/atomic/is_lock_free