Many of these issues you list can be overcome by good coding practise. Although I understand that the framework/languages used allowed for these bad feats.
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 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.
> Many of these issues you list can be overcome by good coding practise.
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.
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.