Erlang systems don't do so well when multiple people are working on them with different understanding of what production is. (And especially if nobody actually knows).
I don't know that you need 'strict access control' as proposed, but you do need coordination, and a source code repository is a way to manage coordination.
Erlang doesn't have a different mode for fixed vs loadable code, although you may need to write code differently in order to be able to hotload changes, and that could affect performance; some code naturally fits the idioms needed though.
I find it amazingly valuable to be able to change the program without having to lose the program state; but it requires different thinking, and it is easy to mess things up in exciting ways that are different than many other systems. It's amazing to fix a bug and deploy it in seconds into a live system with millions of active connections; it's also amazing when you try to fix a bug and break millions of active connections in seconds, but in a negative way, because now you and your users have to pay the costs of reestablishing all of those connections.
OTOH, the key issue is interchange of state and messages between versions, and that's an issue that comes up in almost all distributed systems that update without downtime, so most people have to deal with that issue anyway, just usually not within the much smaller scope of a single task.
I don't know that you need 'strict access control' as proposed, but you do need coordination, and a source code repository is a way to manage coordination.
Erlang doesn't have a different mode for fixed vs loadable code, although you may need to write code differently in order to be able to hotload changes, and that could affect performance; some code naturally fits the idioms needed though.
I find it amazingly valuable to be able to change the program without having to lose the program state; but it requires different thinking, and it is easy to mess things up in exciting ways that are different than many other systems. It's amazing to fix a bug and deploy it in seconds into a live system with millions of active connections; it's also amazing when you try to fix a bug and break millions of active connections in seconds, but in a negative way, because now you and your users have to pay the costs of reestablishing all of those connections.
OTOH, the key issue is interchange of state and messages between versions, and that's an issue that comes up in almost all distributed systems that update without downtime, so most people have to deal with that issue anyway, just usually not within the much smaller scope of a single task.