[elcritch]

It’s nice in that the actor model provides good concurrency. One great benefit is that each "device" or connection essentially runs as a single sequential process. That makes data stream processing pretty nice on embedded. Like processing serial port data. Though it sounds like you almost just want a job queue, which would be pretty easy but not really benefit from actor model.

One example where a Nerves setup would be great is say a redundant onsite mini-cluster for processing and redundancy. As an alternative to say a k8s setup to manage devices with Nerves you could readily flash your "app code" to multiple RPi’s, connect them on a lan, and not have to have a separate clustering layer.

[kitplummer]

For sure, serial data is a factor. I need to dig into the support of GPIO and other serial interfaces (e.g. USB) - but that's a great point. The image distro model is really cool, and need to evaluate that further as well.

[elcritch]

Drop by the Nerves channel on the Elixir-Lang Slack. It’s pretty active and people are pretty helpful.

PS: I enjoy writing streaming code in Elixir (vs more procedural or OO methods). This is a snippet I use to decode a SLIP encoded binary UART stream with an CRC check:

    Stream.repeatedly(fn -> receive_data_packet(timeout) end)
    |> Stream.transform(<<@frame_end, @frame_end>>, &frame_splitter(&1, &2, {separator, max_buffer}))
    |> Stream.map(&decode_slip(&1))
    |> Stream.map(&frame_header(&1))
    |> Stream.reject(&( &1[:code] == -1))
    |> Stream.each(fn x -> if !x[:crc_check] do Logger.error("parser crc error: #{inspect x}") end end)
    |> Stream.reject(&( &1[:crc_check] == false))
    ...