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".
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. :-)
> 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.