3 ms·

Just a quick thought... wouldn't it be a bit more practical to implement this behind some form of "load balancer"-like system at the network/io layer? Are self

Just a quick thought... wouldn't it be a bit more practical to implement this behind some form of "load balancer"-like system at the network/io layer? Are self updating processes really the right abstraction? Seems like it kinda flips reliable build/deploy processes on their head a bit.

robertkrahn01 4y ago
It's definitely a possibility to design some form of RPC mechanism and have multiple parts of your application run as essentially a distributed system. There would still be the problem that the "main" application part is expecting the rest of the system to behave in a certain way and if it is maintaining state, the state to be in a certain form. So I'm not sure that you would really win much. Also, part of the idea is to make hot-reload as little additional burden as possible. Proper compiler support would be the real solution to that but in the form presented in the article you can at least quickly switch between an efficient static build and a dev version, something that would be hard to achieve with an RPC mechanism.
ConnorLeet 4y ago
Sounds like Erlang from what I’ve heard about it
intelVISA 4y ago
Agreed, I made something similar to live patch services w/o downtime and despite being cool I'm not sure I'd recommend it vs. just putting replicated containers behind a load balancer.
infogulch 4y ago
> Are self updating processes really the right abstraction? As a debug tool, absolutely. As as a normal part of program execution in production? A bit sketchy. But that said.... ... what if there was a sure way to directly map your entire program state into the new version and you could be assured that you didn't miss any obscure corner of the state space? Like a borrow checker for transitioning between program versions. That'd be pretty neat.

3 ms·

Just a quick thought... wouldn't it be a bit more practical to implement this behind some form of "load balancer"-like system at the network/io layer? Are self

by nixpulvis 4y ago

robertkrahn01 4y ago
It's definitely a possibility to design some form of RPC mechanism and have multiple parts of your application run as essentially a distributed system. There would still be the problem that the "main" application part is expecting the rest of the system to behave in a certain way and if it is maintaining state, the state to be in a certain form. So I'm not sure that you would really win much. Also, part of the idea is to make hot-reload as little additional burden as possible. Proper compiler support would be the real solution to that but in the form presented in the article you can at least quickly switch between an efficient static build and a dev version, something that would be hard to achieve with an RPC mechanism.
ConnorLeet 4y ago
Sounds like Erlang from what I’ve heard about it
intelVISA 4y ago
Agreed, I made something similar to live patch services w/o downtime and despite being cool I'm not sure I'd recommend it vs. just putting replicated containers behind a load balancer.
infogulch 4y ago
> Are self updating processes really the right abstraction? As a debug tool, absolutely. As as a normal part of program execution in production? A bit sketchy. But that said.... ... what if there was a sure way to directly map your entire program state into the new version and you could be assured that you didn't miss any obscure corner of the state space? Like a borrow checker for transitioning between program versions. That'd be pretty neat.