To whom it may concern 🙃️ In abstract terms, I think of a software system (e.g. a web server, database, message queue, ...) as a collection of dynamic activities. Multiple things are happening: handling of requests, background tasks, periodical jobs, error handling, reporting, and recovery. Many of this things are completely independent, but some of them are working together. These activities have their lifecycles. We want to be able to start the activities in the proper order. We want to be able to dynamically start more activities. We want to be able to stop the activities in the reverse order. If Bar depends on Foo, we want to start Foo first, Bar second, and we want to stop them in the reverse order. Some activities will be decomposed into smaller subactivities. So if Foo internally runs Bar and Baz, we want to be able to stop the entire subtree. For example, if a user hits the cancel button, we want to be able to stop all the activities related to that task. And we want to be able to do this even if the task is stuck in some CPU processing loop. A software system has non-binary success semantics. Just because something fails, doesn't mean everything should stop working. But whatever is tightly coupled to the failing activity should stop too. However, the failing thing should not leave inconsistent mess (state, dangling resources) behind. BEAM & OTP is give us the primitives that address just that. The way I think about my systems in abstract maps very closely to the way I implement them. This vastly reduces the mental overload of thinking about the code. The conceptual view of the system maps very closely to the actual physical model (process structure). This is a power of a good abstraction. For more details, see my talk Soul of Erlang and Elixir, where I tried to explain the underlying ideas. The conceptual properties I mentioned above will have to be supported, because they are inherent to a software system. If you're building a software system without this support, these concerns will get entangled with your business logic. Whether you're doing it manually or vibe it, this work becomes more complicated. You or your agent have to deal with non-functional requirements together with the functional ones. This will make your job and the jobs of agents more difficult. Remember: code is the part of the context, perhaps its largest part. So in the age of agentic development, my position about BEAM remains the same. If you're building a software system, it is the tool that fits the problem, and it will simplify your life. You might bump into situations where some other properties will be more important (e.g. raw processing speed), but you can then implement these parts of your system in another language, say Rust, and manage them from a BEAM-powered system. As many of you know, I'm a long-time user of Erlang and Elixir. But I don't choose those languages for the syntax. For the record, I actually prefer C-style curly-braces syntax. I use those languages because of the runtime properties and guarantees, and because this technology reduces the impedance mismatch between the way I think about the system and the way I implement it. I also actually mostly prefer Erlang syntax over Elixir (minus some exceptions). The reason why I use Elixir is mostly tooling & some language features (e.g. macros). But the choice of the language was never a fanboy choice for me. If you're not building a system, BEAM langs are most likely not your hammers.