I once used CRIU to implement the hacky equivalent of save-lisp-and-die to speed up the startup process of a low-powered embedded system where the main application was misguidedly implemented in Erlang and loading all the code took minutes each time the device started. It worked better than it should have (though in the end it wasn't shipped because nobody (except the customer) cared enough about the startup behavior and eventually the product got canned (for different reasons)).
It was just a bad fit for the problem at hand. It was picked mainly because there were a bunch of Elixir backend devs in the organization that were out of work and every problem looks like a web service (or any other system architecture you're familiar with) if you want it badly enough. There was a bunch of hardware interaction that ended up getting externalized into a separate C++ component that exposed a gRPC interface towards the Elixir component both because of Conway's Law and because nobody wanted to (or knew how to) write NIFs and deal with blocking operations on the Erlang side.
A two-digit number of these devices was meant to form a cluster of sorts and using Erlang clustering sounds like a nice solution for that until you realize that the base load of the full mesh that this implies is high enough to use a meaningful chunk of the device's resources.
> A two-digit number of these devices was meant to form a cluster of sorts...
That embedded constraint is fascinating. With the benefit of 20/20 hindsight, given the same substrate constraint, what direction would you have taken? I was thinking along the lines of maybe a C/C++ state machine library.
