4 ms·

>> and because of the runtime, will practically never crash your system. "Practically never crash" ignores software bugs, resource exhaustion, or bad architect

by belter 1y ago

>> and because of the runtime, will practically never crash your system. "Practically never crash" ignores software bugs, resource exhaustion, or bad architecture

borromakot 1y ago
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....
skrebbel 1y ago
The code can crash but it won't often crash your system (unless you use lots of badly tested NIFs, which most people don't), and that's all GP is saying. BEAM isn't magic but it is pretty robust by now. Tbh I feel like this is not very unique these days, so I'm not sure how this point means a lot, esp in the context of using LLMs for coding. Eg most NodeJS code won't crash your system either (it'll only crash NodeJS).
- throwawaymaths 1y ago
  memory exhaustion is a real thing though. be careful running BEAM applications that do lots of transformations on binary content... PDFs come to mind!

by belter 1y ago

>> and because of the runtime, will practically never crash your system. "Practically never crash" ignores software bugs, resource exhaustion, or bad architecture

borromakot 1y ago

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....

skrebbel 1y ago

The code can crash but it won't often crash your system (unless you use lots of badly tested NIFs, which most people don't), and that's all GP is saying. BEAM isn't magic but it is pretty robust by now. Tbh I feel like this is not very unique these days, so I'm not sure how this point means a lot, esp in the context of using LLMs for coding. Eg most NodeJS code won't crash your system either (it'll only crash NodeJS).

throwawaymaths 1y ago
memory exhaustion is a real thing though. be careful running BEAM applications that do lots of transformations on binary content... PDFs come to mind!