This topic is amazing.
A few things i’ve noticed:
People are taking architectural patterns (microservices/onedbper/etc) that were devised in the context of another system language and interpreting them as if they could be mapped into erlang/elixir.
I contend that BEAM is better thought of as an Operating System environment than being mapped to the UNIX context of system design ( ie: using JVM or GO to ammend the operating system and provide additional layers of abstraction)
In BEAM we are given the tools of an Operating System - Processes, Message, Monitors , etc and in that context we are also given the capability to abstract, layer and isolate our processes and services inside a distributed operating system.
I establish that it’s essential to understand the difference between the container and the content when looking at patterns that have been established for other languages and systems - and the same step is necessary when developing in Elixir Erlang.
I’m saying this because in all my other language and system development experience - having an operating system that is actually working to keep your code running as fast as possible - with as much resources as required - while maintaining a variety of system invariants is alternative to the design of the timeshare unix OS.
Amazing! Here we have an distributed operating system who’s natural building blocks are modules, OTP applications and processes.
Part of the richness of Erlang/Elixir is exactly this and so it behooves us to help guide new and burgeoning developers into the richness and differences of this platform.
The work that PragDave is suggesting to his students is an essential part of this.
Instead of citing patterns that were designed with other constraints in mind - start to discover the new (old) frontier that BEAM is offering!
This could mean discovering effective ways to group and organize code around a cluster, composing and isolate various services inside the context of the language.
Instead of having to fall back and forth between the context of the external timeshare OS and the semantics of a shared memory timeshare process (like a go microservice) that is being externally co-ordinated around other timeshare OS processes ( like a database process ) using a scheduler that is based on the general approach that the machine must be protected from the processes - the OS knows nothing of the critical nature between it’s two processes ( aside what a devop might instruct via runit or it’s cousins)
The BEAM approach is that the ‘OS’ should protect it’s processes, deal with faults and return itself to a known state - where the known state is it’s particualr software and not - in the case of timeshare-os - default form designed to generally run various processes.
This is what makes me excited about erlang/elixir.
Glad for the conversation!
Best,
Curtis RobotArmy
