- Code either "C code compiled with C++ compiler" or C++ OOP Spaghetti like in the CORBA/DCOM days before JEE was a thing.
- functions/methods that span several screens
- barely any kind of testing
- due to emphasis on C style programming, lots of fun tracking down pointer misuses
- re-implementation of code that is already part of C++ standard library, even the ones from C
- lots of copy-paste on the same file because devs don't understand neither source control nor modularity
I wonder how Rust with its focus on memory safety could play out in such scenarios.
I need to have a look at Erlang/OTP. It is a bit of a hidden, alien gem.
I'd recommend it. I think even in the worst case, it's interesting and can change how you approach problems in other languages.
In the best case, it'll fit some problem you have suspiciously well and you'll be left wondering why it only took you a couple of days, a tutorial and 50 lines of easy to understand code to solve a really annoying problem you had.
If some of the syntax or tooling feels like it's getting in your way, Elixir looks like a nice setup on top. Personally I think erlang is fine as it is, though I do want to experiment with Elixir.
The enterprise is not the space for it, specially among companies whose bread and butter is not to sell software.
The only measures of quality management cares about, are "does it work" and "delivers what customers pay for", anything else are just costs that need cutting.
Just like the type systems from Algol family of languages.
Every time a language outsources safety to an external tool, the majority of developers and their employers don't care about it.
Had lint been part of the compiler, like clang did it, instead of external tool, C code would have been much safer than it ended up becoming.
I did, at one of the the companies you list there.
We had outsourced and offshored code for modules on those switches you mentioned.
Have you ever had the pleasure to review C++ code in such type of projects?
I did, and hope to never do it again.