[Thaxll]

It depends of what you mean by state, I was talking about internal state in the application. Your example is about network state like websockets not REST APIs ( what 99,9% of people use ), even with that it's easy to rollout new connections with canary deployment, and with a load-balancer in front of that your replace old instances with new one with no disruption and you can drain your old instances. Even if the connection is cut, in your client logic you should have a proper reconnection mechanism.

Hot code reload is imo a bad practice and should be avoided.

[toast0]

Hot code reload is imo an enabling practice, and should be done everywhere possible. Restart to reload may be useful or practically required for some deployments, and it's sort of a test of cold start, but it's so disruptive and time consuming. I've done deploys both ways, and time to remove host from load balancer, wait for server to drain, then add back is time I won't get back. You can do a lot more deploys in a day when the deploy takes seconds; which means you can deploy smaller changes, and confirm as you go.

[Thaxll]

If it's disruptive and time consuming it means you don't use the right process / tools. If you're CI/CD pipeline is properly setup ( and it's actually easy to do ) you don't have to do anything.

https://kubernetes.io/docs/tutorials/kubernetes-basics/updat...

That's the power of Kubernetes, and since it's very popular the community and tooling are great, good luck replicating that with BEAM.