We manufacture communications equipment, satellite and troposcatter modems. The appeal of Nerves/Elixir was the fault tolerance and small footprint (based on buildroot) compared to the Debian/Yocto type embedded Linux distros. We are not webapp people, we design hardware. The Elixir ecosystem lets us spend more time doing the signal processing and hardware dev and less time working on the various UIs (web/REST/SNMP, etc).

For a specific use case, if you ever fly on Southwest airlines, there’s a 99% chance that your in-flight connectivity is provided by a Nerves-powered modem.

My experience is mostly hobby (not meaning non-involved though) projects (and also the occasionnal freelance gig !), so consider my post with a grain of salt as I don’t experience the scaling and fleet management aspects of Nerves.. yet ?

My experience with creating devices previously meant cobbling together a raspi clone, a few atmegas if precise timing was important, a bunch of python scripts, some C, a system image, and bash scripts to glue everything together.

I guess that you have seen Sasa’s canonical slide with the table, where the right column is all Erlang ?
(https://i.redd.it/tke2stni7l051.jpg)

My experience with Nerves is exactly that. You have an (almost) all-elixir system, access to all of Hex, access to the hardware from Elixir, and the system building part is handled by Buildroot, which makes building your system mostly deterministic. You want to control your hardware from a smartphone ? Sure, just add a Liveview app to your project and configure (in Elixir) the system to create an ad-hoc wifi AP.

The number of moving parts is smashed to an absolute low. It’s a joy working with Nerves, and Nerves also acts as a gateway to learn about building Linux systems, device trees, etc, and go deeper.

I experienced that kind of deep joy when I went all-in on Elixir, and how it reduced the software complexity in my work. But what absolutely blew my hat off was discovering that a similar experience can exist for hardware projects.

I can only encourage every Elixir enthusiast who likes to fiddle to try it — it’s that good.

Yes, power(/grid) management: Embedded and cloud Elixir for grid-management at Sparkmeter - The Elixir programming language

There’s also zola electric using nerves in a similar segment: https://www.youtube.com/watch?v=6MDNm7k2OoI

I cannot really apples to apples compare this to other solutions, which I’ve never deployed in practise. But having worked with nerves at sparkmeter there’s a few observations I can share:

Working on both the nerves embedded device as well as the cloud service it communicated with felt less like two independent projects talking to each other and more like one coherent service, which happens to include a lot of inconsistently available members. There’s not just the “same VM” argument, but there’s a library implementing the protocol (once) used by both sides, there’s a library with shared internal data (again not duplicated) – no real context switch needed. We even considered sharing significant parts of business logic to overcome latency constraints at some point. Elixir makes working with binary data a breeze, which is useful when you need to be mindful of how much data you send, but also for a lot of the communication to other hardware locally.

I can also attest do @Lucassifoni’s points. Nerves takes a bunch of the (one-off) decision making out of the equation, which you’d need to have if you create something just of individual pieces you picked out. It has a path of how you setup the linux system beneigh the elixir service, it brings a tool to keep the system alive (erlinit), it brings a build pipeline, it brings a tool to apply (delta-)updates (fwup).

I’d also add that I don’t think the individual pieces of nerves are particularly special. Most parts or subsets of parts you can find elsewhere as well. But nerves brought them all to elixir (and the beam) and made the pieces work as one complete package.