BEAM
Why I reach for the BEAM in regulated systems
The properties auditors care about - isolation, observability, graceful degradation - are the same ones OTP was built around 30 years ago.
When people argue for the BEAM they usually lead with concurrency. That's real, but it's not why it keeps winning in regulated environments. The reason is that the things a compliance auditor asks about map almost one-to-one onto things OTP already gives you.
Isolation is the default, not a library
A regulator wants to know that a failure in one part of the system can't silently corrupt another. On the BEAM, processes don't share memory. A crash is contained to a process, and a supervisor decides what happens next. You don't bolt isolation on - you'd have to work to remove it.
init([]) ->
SupFlags = #{strategy => one_for_one, intensity => 5, period => 10},
Children = [worker(payment_processor), worker(audit_log)],
{ok, {SupFlags, Children}}.
If payment_processor crashes, audit_log doesn't notice. That's not a
pattern you remembered to apply. It's the shape of the runtime.
Observability you can defend
"Show me what the system was doing at 02:14" is a question you want a real answer to. The BEAM lets you attach to a live node and inspect running processes, message queues, and state without a redeploy. Structured logging plus that introspection means incident timelines are reconstructable, not guessed at.
Graceful degradation reads as a control
Auditors like systems that fail loud and partial rather than quiet and total. Let-it-crash plus supervision produces exactly that: the broken subsystem restarts or sheds load while the rest keeps serving. That behavior, documented, is a control you can point at.
None of this is new. That's the point - it's been load-bearing for decades.