[tieTYT]

How does Erlang deal with these problems? It often touts minimal downtime and the ability to run updates to your code while it's running.

I think that means you can have Process V1 and Process V2 running on the same server simultaneously. If they read from the same database, won't you run into issues?

[jamii]

When you update an erlang module, the vm stores the old and new versions of the code. Calls like foo() call the current running version. Calls like module:foo() call the latest version of that module. So typically you would have all the control flow for a given process in one module and it would use the module call to control when the upgrade happens. At that point it gets to pause and migrate it's data.

The process isolation and code swap mechanisms do give you some help, but when it comes to messages sent between processes you are back in the same boat with API versioning or carefully ordered upgrades.

There is no real magic involved. It takes careful thought and tons of testing to make live upgrades work. Most of the projects I worked on preferred to just eat the few seconds downtime instead rather than risk getting the server into some weird in-between state.

[taeric]

If I understand correctly, this is the point of not modifying the existing data. Current processes will continue to work, as you aren't changing them. New processes will rely on new data (from possibly new stores) such that they shouldn't change what is current.

I could be misreading, of course.