Excellent post, thank you. I am fully for influential voices in the community re-giving a chance to hot code loading.
I’m considering if this is a decent approach to a plugin system for another system I’m working with where plugins might make some sense. And for pure Elixir code this seems perfectly reasonable.
I am using hot code loading in prod to load tenant-specific features that conform to behaviours, so, kind of a plugin system with its idiosyncratic spec. This allows me to have the plugins part of the codebase and monorepo, so they are fully tested by mix test with the rest and in CI. Just at release building time, this source folder (and the matching test folder) is rm -rf’d so they are not included the release.
This, combined with a bespoke script I called an “abstraction boundary checker” allows me to have a nice development experience while guaranteeing that app code never calls plugin code, and plugin code does not call other plugin code. Since the plugins are part of the codebase, an incompatible API change breaks them in dev and test.
When I published an article about that last year, I insisted that what enabled that was my “1 client = 1 instance” rule but I am now doing it in a multi-node cluster with multiple tenants, so my stance about isolation wasn’t a real constraint.
