undefined | Better HN

0 pointsbjourne3y ago0 comments

Imo Erlang's scalability benefits are oversold. Unless you're a national carrier the performance of Java far outweighs Erlang's scalability. Instead, Erlang's undersold killer feature is its robust support for hot code reloading. It enables almost any part of the system to be upgraded without affecting running processes. Other languages and VMs can't do that because they optimize call frames differently and rely on mutable state. It's like building a new road on top of an existing one without impacting traffic. Almost magic and very important for always on services like emergency numbers.

0 comments

kelnos3y ago

I feel like Erlang somewhat missed its timing window on this, though. With platforms like AWS, GCP, and Azure, you don't really worry about upgrade downtimes, because you just roll out a new fleet of servers (or new fleet of pods, if you're using something like Kubernetes), and then drain the traffic from and decommission the old fleet.

Certainly there are a lot of companies managing real physical servers, where this is not as feasible, but I think the ease of server provisioning makes hot code reloading just not that important to most engineering teams.

(And personally I'd be wary of using something like that, considering that the rollback path -- in that case that you deploy bad code and need to back it out -- sounds not as robust.)

chii3y ago

only works if your application consists of stateless requests (like http traffic).

If your application require a persistent connection (e.g., you're a real time streaming service, or video), you will have to write some application specific code to migrate the current state over to the new cluster being provisioned. This is actually quite hard to get completely right, and quite application specific (i mean, a very simple method would be to store some sort of identifying token, and when the new connection re-establishes, you reload the state back from when the disconnection happens).

Erlang lets you do this for "free".

lliamander3y ago

I work in an AWS/K8s-heavy shop, and it is pretty great, but we have a fairly sizeable engineering team.

Managing K8s microservices is easily an order of magnitude more work than managing them in Erlang as applications.

liketochill3y ago

This type of feature is important in control systems where we can modify the process control without interrupting it at all

lliamander3y ago

Yep, I would say that it's support for ops in general is it's biggest strength (deploys, monitoring, fault tolerance, etc.)

j / k navigate · click thread line to collapse

0 pointsbjourne3y ago0 comments

0 comments

kelnos3y ago

(And personally I'd be wary of using something like that, considering that the rollback path -- in that case that you deploy bad code and need to back it out -- sounds not as robust.)

chii3y ago

only works if your application consists of stateless requests (like http traffic).

Erlang lets you do this for "free".

lliamander3y ago

I work in an AWS/K8s-heavy shop, and it is pretty great, but we have a fairly sizeable engineering team.

Managing K8s microservices is easily an order of magnitude more work than managing them in Erlang as applications.

liketochill3y ago

This type of feature is important in control systems where we can modify the process control without interrupting it at all

lliamander3y ago

Yep, I would say that it's support for ops in general is it's biggest strength (deploys, monitoring, fault tolerance, etc.)

j / k navigate · click thread line to collapse