Another thought.
Let me try and define what a component or service might be.
A service is a long lived persistent object with a global or local name that responds to a precise set of management messages.
The management messages determine how the service behaves.
Much of the power of the OTP system comes from the fact that the generic servers etc. all obey the same management protocol.
One can imagine making a simple generic service that responds to start/stop/move_to_new_node/checkpoint/
/hibernate/wake_up/change_code/change_data/connect_port …
Messages.
In a way this is what an erlang gen_server does - but it only has a very small number of callbacks, handle_call, handle_cast, init.
It would be very much more useful if it responded to a larger set of management messages.
Services and components should be understood in terms of the protocols they respond to - and NOT the APIs that hide the protocols.
If there is a fault in how we program Erlang and Elixir it is that we spend too much time thinking about types modules and functions and not enough time thinking about messages and process structure.
Systems are made from black boxes talking to each other - to understand the system we have to understand the messaging and the interconnections. How the internals of a black box work is of secondary importance.
The Erlang model of the world is that everything is an erlang process - and that the only way to influence anything is to send it messages, the only way to learn what things do is to receive messages. This is the purest form of OO programming.
We should build systems of named objects that can send and receive messages between the objects and be notified of failures. The objects should all speak a generic management protocol AND an object specific application protocol.
Think messages and protocols - not functions and APIs.
Cheers
/Joe
