3 ms·

Have you written/deployed Elixir before?

belter 1y ago
Have you deployed critical systems where human lives depend on? "BEAM crashes with segmentation fault #7683" - https://github.com/erlang/otp/issues/7683 https://github.com/erlang/otp/issues/7683 You dont use NIFs ? "A native function that crashes will crash the whole VM." - https://www.erlang.org/doc/apps/erts/erl_nif.html https://www.erlang.org/doc/apps/erts/erl_nif.html "Who Supervises The Supervisors?" - https://learnyousomeerlang.com/supervisors https://learnyousomeerlang.com/supervisors
- borromakot 1y ago
  1. Yes 2. You didn't answer my question? Your answer ""Practically never crash" ignores software bugs, resource exhaustion, or bad architecture" indicates I think ignorance of actually deploying BEAM applications, and instead just making statements based on things you've heard. Isolating failures in software systems is not a bad thing. The developer can choose the boundaries between the elements of their system up to and including "stopping the entire application if things go wrong".
  - belter 1y ago
    Instead of answering on the technical merits of an argument, you went for an ad hominem so...? I ask again...do you use NIFs ? "If the entire computer crashes, you're screwed. you can't really do fault tolerant computation from one machine." - Joe Armstrong And the reason for the quote above is to remind you Erlang/BEAM gives you tools for fault containment and recovery, but not immunity from failure. Say: Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows...And we will conclude in a nice agreement. :-)
    - borromakot 1y ago
      > Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows Correct. > you went for an ad hominem Not my intention. I asked a simple question, and you answered a question with a question, effectively gish galloping me with "but there are ways it can crash" except nobody said there wasn't. It stopped feeling like a technical debate at that point. FWIW, I didn't make the original comment you replied to, I just pointed out that this statement: > "Practically never crash" ignores software bugs, resource exhaustion, or bad architecture felt like a surface response to the OPs sentiment of localized failures not tanking an entire software system.
- freedomben 1y ago
  If perfection is your bar, you're going to be looking for a stack for a very long time.
  - belter 1y ago
    I am not aiming for perfection, just correcting Erlang mythology :-) I can guarantee you Erlang wont save you from an Ericsson AXD301 switch with a full storage...
    - HumanOstrich 1y ago
      What languages/frameworks/runtimes will save you from full storage on a single system?
      - belter 1y ago
        Apparently Erlang....

Have you deployed critical systems where human lives depend on? "BEAM crashes with segmentation fault #7683" - https://github.com/erlang/otp/issues/7683 https://github.com/erlang/otp/issues/7683 You dont use NIFs ? "A native function that crashes will crash the whole VM." - https://www.erlang.org/doc/apps/erts/erl_nif.html https://www.erlang.org/doc/apps/erts/erl_nif.html "Who Supervises The Supervisors?" - https://learnyousomeerlang.com/supervisors https://learnyousomeerlang.com/supervisors

borromakot 1y ago
1. Yes 2. You didn't answer my question? Your answer ""Practically never crash" ignores software bugs, resource exhaustion, or bad architecture" indicates I think ignorance of actually deploying BEAM applications, and instead just making statements based on things you've heard. Isolating failures in software systems is not a bad thing. The developer can choose the boundaries between the elements of their system up to and including "stopping the entire application if things go wrong".
- belter 1y ago
  Instead of answering on the technical merits of an argument, you went for an ad hominem so...? I ask again...do you use NIFs ? "If the entire computer crashes, you're screwed. you can't really do fault tolerant computation from one machine." - Joe Armstrong And the reason for the quote above is to remind you Erlang/BEAM gives you tools for fault containment and recovery, but not immunity from failure. Say: Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows...And we will conclude in a nice agreement. :-)
  - borromakot 1y ago
    > Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows Correct. > you went for an ad hominem Not my intention. I asked a simple question, and you answered a question with a question, effectively gish galloping me with "but there are ways it can crash" except nobody said there wasn't. It stopped feeling like a technical debate at that point. FWIW, I didn't make the original comment you replied to, I just pointed out that this statement: > "Practically never crash" ignores software bugs, resource exhaustion, or bad architecture felt like a surface response to the OPs sentiment of localized failures not tanking an entire software system.
freedomben 1y ago
If perfection is your bar, you're going to be looking for a stack for a very long time.
- belter 1y ago
  I am not aiming for perfection, just correcting Erlang mythology :-) I can guarantee you Erlang wont save you from an Ericsson AXD301 switch with a full storage...
  - HumanOstrich 1y ago
    What languages/frameworks/runtimes will save you from full storage on a single system?
    - belter 1y ago
      Apparently Erlang....