4 ms·

Here's your perfect counterexample. The only language that allows you to build things that won't fail even when the hardware breaks. Erlang.

by j-pb 11y ago

TazeTSchnitzel 11y ago
Even when the hardware breaks? What? If radiation hits the CPU, Erlang won't save you.
- klibertp 11y ago
  It will, if by "Erlang" you mean "language + set of libs + set of conventions (all of this battle-tested for years)". In short: (some) Erlang systems have backup hardware and support moving running systems from one machine to the other (or one cluster to the other, etc), achieving very high "uptime" values.
  - sqeaky 11y ago
    If radiation hits, oh say, a CPU register it might just change the value in a register. That is completely uncatchable and almost unobservable on modern hardware. With any system on relying on hot switching to backups you must have a mechanism to detect errors. The mechanisms exist in many languages there are plenty of robust C++, Java, php, ruby, and sadly cobol systems out there. No new language gets to claim backups as a core feature of the language, unless cobol does too. I am moving to my third job that has a cobol legacy system being replaced by something new. All three of these shops have backup systems that the business owners would never consider separating from their legacy cobol apps.
    - Sanddancer 11y ago
      It is catchable and observable on modern hardware; mainframes have been doing it for years, with the operation also existing on some specialty Intel chips. Cores are paired, with each operation going through each of them simultaneously with the results compared. If the results don't match, they're run through again. If they still don't match, that pair of cores is shut down and operations are redirected.
      - sqeaky 11y ago
        Pairing like that would find this kind of error. It is also believable that mainframe shops would be willing to cut their throughput in half to get that level of reliability. I was completely unaware of it even in a research setting. Yet I was aware of things like ECC RAM, RAID, Chipkill RAM and algorithms for continuous checking of results including some implemented in hardware to isolate faulty CPUs but they all added extra hardware or software and none reused existing commodity cores. Its so simple, of course it should be a thing. Could you post a link to some reading on this?
        Sanddancer 11y ago
        This link from wikipedia has pretty much a good laundry list of descriptions different companies have taken for doing lock-stepping, etc https://en.wikipedia.org/wiki/Lockstep_%28computing%29 https://en.wikipedia.org/wiki/Lockstep_%28computing%29 . It's also one of the reasons this level of machine is so expensive. Each mainframe core would be two cores in a "normal" system, plus mainframes have logic to decommission a cpu without needing a shutdown, by migrating the workload to a spare processor.
        sqeaky 11y ago
        I only spoke with such confidence in my previous post because I thought I had worked on high end machines. I worked with a number of Sun and oracle machine with CPU failure detection and CPU hot swapping. But This feature was always flaky. I am eager to learn about what I missed.
r0naa 11y ago
It would be nice if you could add a citation, or elaborate a little bit!
- vezzy-fnord 11y ago
  I think the parent poster's point is more that the article's extensive focus on side effects and monadic encapsulation as the central concern for reliable software engineering is short-sighted, as Erlang is a dynamically typed impure functional language that nevertheless is robust in its use of multi-node distribution, supervisor trees, sophisticated error/exception models, scheduling guarantees, SMP, dynamic code upgrade as first-class VM constructs, as well as the language itself being homoiconic and driven by a small number of basic data structures (tuples and lists). The language's module system offers namespacing and then the OTP framework implements standard behaviors that have (in gen_server's case) state calculation, supervision, code change, termination and messaging callbacks all exported. I presume "surviving hardware failures" was in reference to native Erlang epmd machine distribution, which is intended for fault tolerance and based on heartbeats. It's one step further than most languages go. Ultimately, there is much more to be considered than state and side effects.
  - j-pb 11y ago
    Yes, exactly. Well put :)
hueving 11y ago
What? The only possible way that constraint could be satisfied (working under any hardware failure) would be if erlang didn't let you write any programs that did anything.
- fnordsensei 11y ago
  Excuse the aside, but this reminds me of this old Bash quote: <FreeFrag> The most secure computer in the world is one not connected to the internet. <FreeFrag> Thats why I recommend Telstra ADSL. Also, agreed. Some elaboration on that point would be most welcome.
  - TazeTSchnitzel 11y ago
    http://bash.org/?168859 http://bash.org/?168859
- thyrsus 11y ago
  The argument is that Erlang (and its OTP environment) gives you the tools to distribute your system in such a manner that hardware failure is observed and that the failed portion of the system is restarted elsewhere. The granularity provided is better than most STONITH models. It provides a lot of help, but one still needs to make an effort to assure that, e.g., merchandise is not sent unless an invoice is generated. STONITH: https://en.wikipedia.org/wiki/STONITH https://en.wikipedia.org/wiki/STONITH
marcosdumay 11y ago
In theory, Haskell could do that too. Some people even started a fork of GHC aimed at cluster parallelism a few years ago, but I don't think they got it working.

Here's your perfect counterexample. The only language that allows you to build things that won't fail even when the hardware breaks. Erlang.

by j-pb 11y ago

Here's your perfect counterexample. The only language that allows you to build things that won't fail even when the hardware breaks. Erlang.

TazeTSchnitzel 11y ago

Even when the hardware breaks? What? If radiation hits the CPU, Erlang won't save you.

klibertp 11y ago
It will, if by "Erlang" you mean "language + set of libs + set of conventions (all of this battle-tested for years)". In short: (some) Erlang systems have backup hardware and support moving running systems from one machine to the other (or one cluster to the other, etc), achieving very high "uptime" values.
- sqeaky 11y ago
  If radiation hits, oh say, a CPU register it might just change the value in a register. That is completely uncatchable and almost unobservable on modern hardware. With any system on relying on hot switching to backups you must have a mechanism to detect errors. The mechanisms exist in many languages there are plenty of robust C++, Java, php, ruby, and sadly cobol systems out there. No new language gets to claim backups as a core feature of the language, unless cobol does too. I am moving to my third job that has a cobol legacy system being replaced by something new. All three of these shops have backup systems that the business owners would never consider separating from their legacy cobol apps.
  - Sanddancer 11y ago
    It is catchable and observable on modern hardware; mainframes have been doing it for years, with the operation also existing on some specialty Intel chips. Cores are paired, with each operation going through each of them simultaneously with the results compared. If the results don't match, they're run through again. If they still don't match, that pair of cores is shut down and operations are redirected.
    - sqeaky 11y ago
      Pairing like that would find this kind of error. It is also believable that mainframe shops would be willing to cut their throughput in half to get that level of reliability. I was completely unaware of it even in a research setting. Yet I was aware of things like ECC RAM, RAID, Chipkill RAM and algorithms for continuous checking of results including some implemented in hardware to isolate faulty CPUs but they all added extra hardware or software and none reused existing commodity cores. Its so simple, of course it should be a thing. Could you post a link to some reading on this?
      - Sanddancer 11y ago
        This link from wikipedia has pretty much a good laundry list of descriptions different companies have taken for doing lock-stepping, etc https://en.wikipedia.org/wiki/Lockstep_%28computing%29 https://en.wikipedia.org/wiki/Lockstep_%28computing%29 . It's also one of the reasons this level of machine is so expensive. Each mainframe core would be two cores in a "normal" system, plus mainframes have logic to decommission a cpu without needing a shutdown, by migrating the workload to a spare processor.
        sqeaky 11y ago
        I only spoke with such confidence in my previous post because I thought I had worked on high end machines. I worked with a number of Sun and oracle machine with CPU failure detection and CPU hot swapping. But This feature was always flaky. I am eager to learn about what I missed.

r0naa 11y ago

It would be nice if you could add a citation, or elaborate a little bit!

vezzy-fnord 11y ago
I think the parent poster's point is more that the article's extensive focus on side effects and monadic encapsulation as the central concern for reliable software engineering is short-sighted, as Erlang is a dynamically typed impure functional language that nevertheless is robust in its use of multi-node distribution, supervisor trees, sophisticated error/exception models, scheduling guarantees, SMP, dynamic code upgrade as first-class VM constructs, as well as the language itself being homoiconic and driven by a small number of basic data structures (tuples and lists). The language's module system offers namespacing and then the OTP framework implements standard behaviors that have (in gen_server's case) state calculation, supervision, code change, termination and messaging callbacks all exported. I presume "surviving hardware failures" was in reference to native Erlang epmd machine distribution, which is intended for fault tolerance and based on heartbeats. It's one step further than most languages go. Ultimately, there is much more to be considered than state and side effects.
- j-pb 11y ago
  Yes, exactly. Well put :)

hueving 11y ago

What? The only possible way that constraint could be satisfied (working under any hardware failure) would be if erlang didn't let you write any programs that did anything.

fnordsensei 11y ago
Excuse the aside, but this reminds me of this old Bash quote: <FreeFrag> The most secure computer in the world is one not connected to the internet. <FreeFrag> Thats why I recommend Telstra ADSL. Also, agreed. Some elaboration on that point would be most welcome.
- TazeTSchnitzel 11y ago
  http://bash.org/?168859 http://bash.org/?168859
thyrsus 11y ago
The argument is that Erlang (and its OTP environment) gives you the tools to distribute your system in such a manner that hardware failure is observed and that the failed portion of the system is restarted elsewhere. The granularity provided is better than most STONITH models. It provides a lot of help, but one still needs to make an effort to assure that, e.g., merchandise is not sent unless an invoice is generated. STONITH: https://en.wikipedia.org/wiki/STONITH https://en.wikipedia.org/wiki/STONITH

marcosdumay 11y ago

In theory, Haskell could do that too. Some people even started a fork of GHC aimed at cluster parallelism a few years ago, but I don't think they got it working.