Generic Server

All good ideas are old

To run our cluster of Nerves instruments and our 900 LED tree at Goatmire we used a laptop running a repo called "conductor". Every instrument ran the same code. They got a static IP assignment based on their MAC address giving them an easy identity. Conductor carried config files that enumerated all the devices we intended to work with. Conductor knew what needed to be done, conductor drove the LED effects over the network. Everything except the MIDI playback was done from conductor. To make the MIDI reliable timing-wise it had to run on each instrument. It was still kicked off by conductor, the .mid files were sent out by conductor.

Having the devices be a blank slate meant we rarely needed to update them during development. The scheme was actually very convenient.

And it makes me think of Joe Armstrong's favorite Erlang program. The Universal Server.

I am gearing up to give a talk at Oredev and the blurb I submitted is essentially about what makes our runtime so great (better than theirs ; ) and there are many ways to cover that ground. And going back to Joe's idea to some extent is interesting.

As long as I keep my fundamentals in good order with regard to OTP version, Elixir version and some nuances around handling NIFs there is nothing stopping me from starting an almost blank device and then shoving new code at it to bring it to life. Iterating by replacing modules. Stopping and starting applications.

The Erlang runtime was always an operating system. And it was made to do these things. Hot code updates, loading and unloading modules and apps. We don't generally do that in production these days but a bunch of the underpinnings that make this possible is what makes our system so powerful at runtime. The introspection, the isolation, the certainty that many things will be happening and they all need their time with the CPU. The runtime is as good and powerful as it is because it was intended to do stuff that was much, much harder in much more sensitive circumstances.

If you have favorite things about the runtime, pitch them to me in a reply. My inbox is open and maybe you'll make my talk better and sell some more people on the BEAM with me as I gear up for one of Sweden's largest developer conferences.

Thank you for reading, I appreciate you spending some your attention here.

-Lars