3 ms·

But suitability is a huge factor here. The point isn't that "nine nines" reliability cannot be achieved in C++ or whatever, it's that it's significantly harder

But suitability is a huge factor here. The point isn't that "nine nines" reliability cannot be achieved in C++ or whatever, it's that it's significantly harder and costlier to achieve. 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.

gpderetta 10y ago
> Null pointers are impossible in Erlang, whereas they are provable impossible to avoid in C++. 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.
- jlouis 10y ago
  Don't underestimate the cost of trivial maintenance. In any project constrained by time, you risk people skipping on these things in part of the system. Erlang/Elixir is pretty well built for robustness, so a single library is less likely to affect the system as a whole. The same cannot be said for C++, where every part has to be close to correct for the operation to proceed as you expect. 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.
- lobster_johnson 10y ago
  Not trivially, no. Even if you try to avoid "raw pointers", C++ is an unsafe language by design, and it's non-trivial to turn it into a verifiably safe one: * 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.
  - gpderetta 10y ago
    Note I was explicitly objecting about null pointers begin impossible to avoid. My claim is that the C++ type system allow avoiding them just fine. I'm making no claim about general the memory safety of C++, and its issues are well known.

gpderetta 10y ago

> Null pointers are impossible in Erlang, whereas they are provable impossible to avoid in C++. 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.

jlouis 10y ago
Don't underestimate the cost of trivial maintenance. In any project constrained by time, you risk people skipping on these things in part of the system. Erlang/Elixir is pretty well built for robustness, so a single library is less likely to affect the system as a whole. The same cannot be said for C++, where every part has to be close to correct for the operation to proceed as you expect. 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.
lobster_johnson 10y ago
Not trivially, no. Even if you try to avoid "raw pointers", C++ is an unsafe language by design, and it's non-trivial to turn it into a verifiably safe one: * 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.
- gpderetta 10y ago
  Note I was explicitly objecting about null pointers begin impossible to avoid. My claim is that the C++ type system allow avoiding them just fine. I'm making no claim about general the memory safety of C++, and its issues are well known.