> It has since expanded into numerous other areas, such as web servers, and has achieved nine 9s of availability (31 milliseconds/year of downtime).
I definitely want to read more about this.
I definitely want to read more about this.
This claims from a study of a particular model of Ericsson's ATM switch whose software was written in Erlang.
A can tell you for sure that: * Ericsson has other switches and other telecom equipment whose software is written in C++ * other companies (Nokia, Cisco, Alcatel etc.) also built similar complex telecom equipment whose software was in C++
I'm going to bet that at least one of those devices was more reliable than that particular switch, because it's not the language that creates reliability but people writing and testing the software.
Some languages make it easier than others but attributing some magic qualities from extrapolating a single case study of a telecom equipment is just silly.
Telecom equipment is reliable because it has to be. If you're incapable of writing reliable software for telecom equipment then your company will go bankrupt and be replaced by one that can, even if the language they use is C++.
https://en.wikipedia.org/wiki/Erlang_(programming_language)
It also had this along the same lines though:
>As Tim Bray, director of Web Technologies at Sun Microsystems, expressed in his keynote at OSCON in July 2008:
"If somebody came to me and wanted to pay me a lot of money to build a large scale message handling system that really had to be up all the time, could never afford to go down for years at a time, I would unhesitatingly choose Erlang to build it in."
But also: Of course a language creates reliability. Null pointers are impossible in Erlang, whereas they are provable impossible to avoid in C++.
So people bring this up because Erlang programs are pretty much reliable by default (assuming you stick to OTP and its design).
To help it reach insane uptimes, Erlang also has a few features that are hard to replicate in C++, if not impossible. The main one is hot code replacement; being able to incrementally upgrade a system in a safe and controlled manner without restarting it is a huge benefit in such a system.
It's also trivial to attach to a running Erlang program and introspect it as if you're truly running inside it. Goes hand in hand with hot code replacement. With C++, you get fairly crummy, low-level things like gdb, without the ability to actually write C++ code while in the debugger.
Also, remember that crashes can occur in bug-free programs. Hardware failures can be hard to predict and handle.
They are trivially possible to avoid in C++ as you do not have to use raw pointers. References, value types, custom non-null smart_ptrs, etc.
The trade-off you get however, is that the explicit control in C++ tend to produce systems which run faster under nominal operation.
In practice, many Erlang systems contains some C/C++ parts at their core for fast operation. Depending on their complexity, you try to isolate them from the rest of the system as much as you can. In short, you use Erlang as a top-level control backplane for your C/C++ code. The advantage is you get the speed of C++ where needed, but the added productivity of Erlang everywhere else.
Erlang programmers are usually practically minded in this regard. "functional purity" doesn't really matter that much if the problem isn't solved.
* Even smart pointers are still pointers, which are trivial to access after release by mistake; and references are only safe as long as the caller still exists. C++ does not have anything like Rust's borrow checker.
* C++ threads allow race conditions that can screw up even smart pointers.
* Plenty of libraries (C and C++), which are usually impossible to avoid and completely impractical to vet, will still use raw pointers.
Generally, the word "trivial" and C++ don't go well together.
I'm making no claim about general the memory safety of C++, and its issues are well known.
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.
- 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.
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'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.
Interesting result from this study - erlang implementation is not only more robust but also faster.
Lightweight processes, messaging, OTP, supervision all play a role when it comes to runtime fault tolerance.
Erlang is a rare beast in that the language and its VM are both very opinionated and very focused on certain types of problems (such as telecom and fault tolerance). This is not Java and its VM trying to be all things to all people.
1) Go will crash or at minimum (arguably much worse) go into an unknown state.
2) C++ will crash, and ideally, restart, but lose all "live" state. (So calls get dropped, etc.)
3) Erlang/Elixir process will crash and then get instantly restarted by the supervisor. If the bit flip hit the supervisor instead, then its supervisor will restart it (most larger BEAM apps have a supervision hierarchy). The only way BEAM will go down is if the cosmic ray hit BEAM.
Checkmate, non-BEAMs? ;)