Just a clairification on Nerves - it is still full OTP / Elixir, but bundled for embedded systems.

A couple of other points worth considering:

1. Erlang & Elixir’s binary parsing approach using pattern matching is very powerful. If you are having to implement different control system protocols this approach can potentially significantly reduce effort. You can see a worked example here: Binary pattern matching in Elixir with PNG parsing example (first result from a google search)
2. The BEAM was designed specifically to hold lots of concurrent conversations with extremely high reliability - it was built for telco switching systems. It isn’t good if 100,000 conversations get killed because of one mishap in one single conversation. Erlang/Elixir almost certainly gives you the shortest path to fault-tolerance while holding multiple “conversations” with multiple in-field devices.
3. RabbitMQ - a pretty well known message queue infrastructure - is written in Erlang (same platform as Elixir). You can take a look at the source here: GitHub - rabbitmq/rabbitmq-server: Open source RabbitMQ: core server and tier 1 (built-in) plugins · GitHub. Again - speaks to the reliability and ability to do many things at once.
4. While go has the big advantage of packaging pretty much everything into a single binary through the compiler & linker, mix release does an excellent job of bundling an Elixir application into a single folder for deployment.
5. The performance characteristics when a BEAM-based system is under load are generally quite attractive. Latency/performance tends to gradually fade as load increases, which means you have time to do something about it before it becomes a disaster. If I can recall the talk I’ll add the link! (@wanton7 mentions this in hist list)
6. Batteries included - caching, queuing, multi-CPU concurrency, background jobs, web-serving, API creation / consumption etc can all run off the one codebase. While Elixir applications may not deploy as a single executable, they can deploy as a very simple stack.
7. Serious engineers in the community. So I don’t know much about the Golang community (although I do know that there are some very talented folk in it), but the Elixir & Erlang community has, in my experience, been very open & generous, but also very thoughtful about how long-term, robust, low-hype, sustainable software should be built. It has a low presence on stack overflow relative to other languages (possibly downside when trying to convince pointy-haired bosses that it’s the right choice), but if you know where to look and make an effort to help yourself, help is never far away. The telco platform roots almost certainly have something to do with the serious side, but the Elixir ecosystem leaders such as José, Chris & @AstonJ keep it very human and welcoming.

If you haven’t watched this video yet, you should: https://www.youtube.com/watch?v=JvBT4XBdoUE - it really brings to life a few of the concepts covered in this thread and a very worthwhile investment of 42mins IMO.

Good luck with your project - it sounds pretty cool! I spent a few years working for an industrial control system vendor and do think Elixir could take a lot of complexity out of SCADA systems & similar where hard real-time isn’t needed. If you do go this route, I’d love to hear how you go.

We are doing a very similar thing right now.

The system we have to replace is a RPi-CM based mini-server which

• serves a visualisation for a smarthome (HTTPS server, OAuth2)
• connects to various field busses (RF and cable)
• provides a Hub for those (similar to, but not as feature rich as: https://www.home-assistant.io/)
• handles some hard-keys and LEDs
• is OTA-updateable

The current system uses:

• python (Hub, some scripts)
• node (server)
• C and Cpp (bus stacks)
• .deb (updates)
• bash (some scripts)
• systemd
• crazy test system
• …more

We decided to go for Elixir/Nerves for the next generation.
@mindok has very nicely summarized the reasons for that decision, but I want to point out:

• functional language (Elixir or Erlang is the only functional language I’d consider for an embedded system. Functional languages have great advantages I won’t go into here, but the biggest plus I expect is better testability)
• we can do everything (but some fast-hard-realtime stuff) in one language. This is a big plus, especially for a small team.
• possibility to run on small platforms like iMX6UL - even without Linux, see GRiSP2
• erlang’s binary pattern matching is a game changer when implementing protocols (I did put Elixir to the test by implementing the part of the system I saw it least fit for: the KNX protocol stack. This turned out very nicely)
• Nerves is a great tool for building embedded software systems and makes OTA updates simple. (Our current desktop-OS and .deb system is a pain in the ass with thousands of servers in the field)
• OTP (Supervision tree kills systemd, we can create on (umbrella/poncho?) project for the whole system.)
• Elixir is a great language, with a very good ecosystem including a great community. There are lots of people here, that are here because they’ve already seen some other stuff.

Go doesn’t really make any assumptions on what you need app and data structure wise, but does make a fair number of them when utilising the standard library for networking, database pools etc. It’s always been irritating that Go forces the user to write known structures, such as sets because Go strives for simplicity (when in truth, is anything but).

Anyone can walk through the excellent Go by Example and up out knowing how to write Go provided that you come from a C background, but I find that alone is insufficient in any sort of application design. While the messaging from Go is that there’s “one” way to do things, it’s hardly the case as pages such as Effective Go and CodeReviewComments · golang/go Wiki · GitHub are necessary to get some confidence in Go itself.

While Go is incredibly fast, it lacks robust in-built fault tolerance which is a deciding factor at scale. There’s an excellent video https://www.youtube.com/watch?v=40d26ZGfhR8 which illustrates the key differences between Go and Erlang; especially on what Erlang does (process isolation, in-code reloaded etc), which simply doesn’t exist in Go outside a third library. In short, the video concludes that tools such as Kubernetes smooth the edges with Go, especially around Go panics which can, if done incorrectly, can tear your entire application down abruptly. This reinforces my prior point; Go can be written quickly, but you have to be extremely defensive and write code to handle those instances, made somewhat worse by Go’s anemic error handling.

If you do decide with Go, you have to cater to the possibility of unexpected application shutdown and ingrain some sort of behaviour that kicks in when it occurs. It could be systemd, or Kubernetes, but you’re forced to acknowledge that runtime errors can propagate to application errors and have to plan accordingly. In Erlang, while this can happen, you have in-built measures in places to ensure that the application isn’t compromised in the presence of runtime errors.