Hacker News Reader

Comment by kitplummer | Hacker News Reader

Fairly blind question: does Erlang|Elixir and BEAM make any sense in a pseudo-embedded, edge compute or IoT environment with constrained resources (CPU and memory), or even ARM architecture? Aside from the developer-side things, if AMQP were to the centralized communications hub (e.g. RabbitMQ) does using Nerves on devices make any performance benefit - meaning BEAM and app(s) there?

The intent would be pre-process data and stream inward, or simply be a command-and-control interface -> process and provide response.

View on HN

Yes, take a look at nerves : https://nerves-project.org/

Yep, know Nerves. Like the toolset and the model. Really asking about the underlying Erlang/Elixir that Nerves provides. The delivery flow (think image to SD card) fits the more tradition embedded/realtime model - versus OS, and installing app.

Well a Nerves image is a Unix Kernel + Erlang/Elixir & BEAM and whatever else you need, so its a completely stripped down image. It uses the Whitelist model so you add what you need instead of removing what you don't need. This is both more secure and more performant since you don't have 100's of apps/services running in the background, you only run what you need.

You can control everything remotely with nerves-hub, push update, debug etc. Remember you only have to burn the image once, then its all update from here.

You can build a poncho application where everything is side-by-side, lets say you have your app-firmware (you build image from this), then you build separate app-ui, app-logic, app-whatever etc. and simply hard code the path as dependencies in app-firmware and each app has their own configuration.

Everything will be bundled into a single image and protects you from things leaking in from the sides rather than from above.

They make the most sense if you want lots and lots of simultaneous clients. Plus it gives you a little bit of safety if you write crappy code.

Typically not suited for embedded.

(Assuming you mean embedded as in severely limited in resouces, and not "modern embedded" where you have lots and lots of unused system resources. If you mean the latter then anything goes.)

Yep, modern embedded (e.g. rPi and other Intel-based devices). I suppose there would be limited connections from each device, but many devices.

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.

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.

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))
    ...

Maybe not production ready but there's https://github.com/bettio/AtomVM (BEAM on a ESP32)

Reply on news.ycombinator.com