That’s not really true stated like that. All the capabilities are available if you look at hot code updates. Even in releases you can just copy paste modules into the console and they’re compiled and kept in memory until the vm stops. The BEAM was built to explicitly allow for not needing to shutdown the system while the underlying codebase is continuously updated.
But there’s a lot more to maintaining a working system than compiling and loading modules and those are the problematic pieces. There’s updating state correctly besides changed code, there’s maintaining compile time dependencies between modules if macros are involved, there’s runtime dependencies between applications and modules, which require maintaining a certain load/startup order. And all of those also might fail, and those failures need handling.
The available APIs for the above are either quite low level (see e.g. Code) or to my understanding tightly coupled to building releases and doing hot code updates. There’s probably also a lot in the code bases of mix or rebar when it comes to dependency management, but I doubt there being much public API for those pieces.
By the parts I know I’d expect someone attempting to build such a system to need to know not only elixir programming, but also quite a bit about how the beam load/starts applications, how releases are structured, where compiled files need to go, how to cleanup things supposed to be removed and as mentioned how hot code updates deal with all the runtime complexities of updating code for a running system.
The security factor imo in the end boils down mostly to how well the code is audited before being loaded, given there’s no sandboxing on the beam just like in php. This feels like a separate topic to being able to actually load the code though. To me a plugin system from a security standpoint is no different to adding dependency :xyz to a plain old mix project and deploying the changes. When nobody looked at :xyz before putting it on a running system that’s a problem.
