I do it from the start, unless I am only prototyping 
Exadra37
Sebb
When looking into the functional core, imperative shell pattern I found this
All code can be classified into two distinct roles; code that does work (algorithms) and code that coordinates work (coordinators). [kbilsted/Functional-core-imperative-shell]
This puts the finger on the problem I had with my original implementation. The protocol-layers do their work, but in the middle sits this annoying randomly acting coordinator. The coordinator does not really behave better, if it is split into multiple modules. It has to be removed from the core and pushed to the boundaries (shell) of the application. (Just like I like management, sales and marketing on a different floor, or even better: building)
2
Sebb
Refactoring the stack with the functional core, imperative shell pattern was a really pleasant experience. We have now decided to build a prototype of one our products completely in Elixir, replacing:
- multiple C and Cpp-modules
- node.js/express
- python
- cron
- systemd
- homebrewn OTA-updater
- MQTT,
- openvpn (maybe)
- couple of bash-scripts
- … (I’m sure I’m missing some)
Right now I don’t see what we need besides Elixir, OTP, phoenix, nerves(hub), some C for hard-realtime stuff and a couple of lines in Go to talk to the cloud.
But I’d like to also try the
Do I understand correctly that’s just sth like
def layer_0_handle(packet) do
packet = ...
layer_1_handle(packet)
end
def layer_1_handle(packet) do
packet = ...
layer_2_handle(packet)
end
and so on?
3
hauleth
Elixir cannot replace that one to be honest. These two have different purposes in the OS lifetime and can nicely complement each other, but not replace.
0
NobbZ
Usually I’d agree with you here, though as Sebb mentions Nerves it is probably some Raspberry Pi running the current stack on a raspian.
In this scenario, the Nerves-init system is indeed the only way to go and replaces systemd.
2
Sebb
sasajuric
Author of Elixir In Action
Something like that, but based on behaviours. The idea was to build each layer as a behaviour, i.e. something GenServer-like. The bottom layer (0) would internally use e.g. gen_tcp or ranch (assuming tcp is the transport). An upper layer would be implemented on top of the bottom one, e.g.:
defmodule Layer1 do
@behaviour Layer0
# define layer1 callbacks
@callback ...
@callback ...
...
def start_link(arg), do: Layer0.start_link(__MODULE__, arg)
# layer0 callbacks:
@impl Layer0
def handle_packet(layer_0_packet, state) do
layer_1_packet = decode(layer_0_packet)
# fire the event to the upper layer
state.callback.handle_packet(layer_1_packet)
...
{:reply, layer_0_out_packets, new_state}
end
...
end
4