Through its roots in Erlang, Elixir's robustness and reliability are often mentioned as its greatest advantages. The ultimate example of this being...
For further actions, you may consider blocking this person and/or reporting abuse
Thank you Jeff, all this stuff is amazing. Love that the final version is more functional, passing the state in the recursive function.
I'll have to learn Elixir at some point.
You inadvertently reminded me of NGINX's own upgrade functionality, in which it spawns a new master process which in turn spawns a new set of workers and then tells the old ones to finish up what they are doing and then die.
Another thing you reminded me is that Go from 1.11 supports loading third party modules in different versions in the same application/binary. I guess someone will come up with hot module reloading for that feature too creating a pluggable system.
It's awesome that all of this is "free" in Elixir/Erlang.
Bookmarking to digest this more later after work. Hot reloading is one of those things that's magic about Elixir, you hear what it does and you're like: "What I can do that?!"
Also, if you need Elixir app monitoring and performance metrics, AppSignal is the best I've used hands down. It's really easy to set up with Phoenix projects.
Ah ah sure ;-) I was spitballing ideas just for the sake of them. It makes way more sense to build the server on top of Elixir if you need Erlang VM's features
This put me in mind of the Windows Installer service, oddly enough. DLL updates work in much the same way, allowing running applications to keep using the old version of the DLL, while any new processes will load the new one.
I wouldn't consider it stillborn but right now it's pretty hard if not impossible yes.
Go doesn't have a "runtime VM" nor the ability to load multiple versions of the same plugin.
But, let's enumerate a few possible useful "legos" to build such functionality:
So, a giant maybe, you could ship a server with multiple binaries handled by a different goroutine each, all monitored by the supervisor tree and then tell the supervisor tree it needs to tell the goroutine to die (with channels) when done and spawn another one with the new shipped binary.
Does it make sense? It's definitely not the same thing but if the app is organized in this way it might come a little closer to what Elixir and Erlang have.