OTP = Open Telecom Platform [1], though I think the full name is avoided nowadays.
On an unrelated note, I've always been fascinated with the Erlang VM. The idea that you could hot-load modules and have multiple versions of the same module running at once seems really useful. I wonder why other runtimes haven't adopted these features?
Hot loading in Erlang is not magical. Here is an example. Let's say you want to redeploy some new code. In your deploy, you change some existing function foo in module A to call a new function bar in module B.
If you do this, you'd better make sure that you hotload the new version of B before you hotload the new version of A. Otherwise some process could end up trying to call B:bar through A:foo before the new B has finished loading.
If you rely on hotloading modules as your primary deploy mechanism, you will run into issues like this all the time. So it's not really clear to me that hotloading is a win for your typical stateless web service compared to just deploying a new binary and doing your standard zero-downtime deploy via forking.
It makes more sense when you realize that certain Erlang apps build up a huge amount of state in-memory. In those cases hotloading allows you to load new versions of the changed modules without having to take down the whole VM.
> I wonder why other runtimes haven't adopted these features?
Probably mainly due to shared memory. When you know your data can be modified only in one place, changing data structure is easier. Try changing a struct when some other code is using it. It would require a lock for every object in memory.
One of the great things about Erlang and the BEAM is that by designing a very opinionated language around concepts like immutability and ubiquitous messaging between lightweight actors, you can define the VM to support those.
So there’s this collection of features between the language and VM that support each other, and are generally hard to reproduce outside that ecosystem because they are so interdependent.
the fact that looping through a process is a tail call which by its very nature creates well-defined boundaries (both in "code segment" and in "data segment") also helps a gazillion. Try doing hot loading in the middle of a while loop... Not saying it's impossible, but you're not gonna have a good time.
It's no longer considered a correct acronym as erlang is not really a telecoms language anymore. It's been a problem where outsiders are quick to think or say, "I am not writing a telecoms app" and dismiss it.
I understand this reasoning. The conclusion I draw is that "OTP" is truly a miserable name — like "car cdr" level bad.
As a newcomer to Elixir's OTP, I cannot divine that experts hold the opinion that the acronym expansion is misleading when that information is deliberately withheld. The first thing this article did was send me off to search the web.
Folks should use a backronym, like "Opinionated Threading Platform".
OSGi (Open Services Gateway initiative) [1] provides this for the JVM by modularizing the ClassLoader [2]. If a module is upgraded but classes from the previous version are still referenced by other modules, both modules will run.
An OSGi "service" is not an actor but, like OTP with servers+supervisors, is the logical unit with which you build your systems. "bundles" (Java JARs with additional metadata) then act as the equivalent "application" that contain the services.
Outside of it being Java, I have strong opinions (positive and negative) that I've decided not to include.
Because why would you do that? Now we have tool and pipeline where testing / deploying ect .. is easy, so I'm not sure why would I risk to do hot load things.
I don't think it's useful and I think it's pretty dangerous is the first place. You have code that can run two different things, wcgw.
1. You can use this during development (where the tight feedback loop is very nice).
2. You can use this during deployment (after verifying that the process will work as intended, hopefully).
(1) is something you could do every day if it was your daily driver language. (2) would happen less frequently (well, as frequently as you deploy) but permit you to do partial updates without bringing the whole system down.
It's worth remembering that deploying Erlang (and Elixir) can be more like deploying with microservices or applications to an application server. You don't want to bring the whole thing down just to change out one part of the system, so you can update just the parts that have changed and need to be updated.
Because control plane does not handle anything phone related most likely? It's like upgrading Kubernates masters, your API servers still works and are not affected.
AFAIK Erlang code does not handle any network traffic, all of that is done in C/C++.
Regardless of where the call is handled, you can't just deploy a new switch in a telecom network, but you still want to upgrade them. This is where you really want hot code loading.
Real world usage case - I have a server which handles several thousand telematic devices (telemetry+actuation), split into about 20 different device types. It's small device base so doesn't require multiple servers and we can be really cheap. But requiring to disconnect all devices just to make one small change to one device driver would be painful. Now we can have uptime of over half a year and in that time we had changes/fixes to several drivers. Normally that would require scheduled downtime every week and slow us down considerably.
I think (could be wrong) it's used for hot code reloading in phoenix when you're in dev mode. Make a change in your code, hit refresh in the browser, and now the relevant code deltas are applied to your http request.
Someone correct me if I'm wrong here, but afaics dropping the ability to do it would remove a complication from the platform and wouldn't affect the vast majority of users in any way. But [afaik] it has to exist because Ericsson require that feature. Outside of their specific usecases it's doesn't seem a particularly useful feature, or one that is used in the vast majority of contemporary codebases
Then they really need to pick a new name, because OTP is widely understood in programming to be a “One-Time Pad”, and without defining what they think it means in this context this is the least coherent article I’ve read in a while.
On an unrelated note, I've always been fascinated with the Erlang VM. The idea that you could hot-load modules and have multiple versions of the same module running at once seems really useful. I wonder why other runtimes haven't adopted these features?
[1] https://en.wikipedia.org/wiki/Open_Telecom_Platform