Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir/Erlang Hot Swapping Code (2016)

kennyballou.com

Post reply on HN
Print view View original

111–119 of 119 posts

Re: Elixir/Erlang Hot Swapping Code (2016)

#111

Post by knome »

Muromec wrote: post #97
knome wrote: post #91

Earlier quoted context omitted.

erlang has a code_change function in the otp that allows the gen_server to update its current state and start using new code. No connections need be broken with clients, no long running processes need be stopped. Just updated in place. It's not just a routing change. https://www.erlang.org/docs/24/man/gen_server

It's a routing change in a sense that gen_server is routing function calls to the new module definition. I know about gen_server and code_change, the point was that conceptually the same mechanism, just on a different level of abstraction.

Routing in progress connections to a new module seems a rather different thing to me than merely routing new ones.

Re: Elixir/Erlang Hot Swapping Code (2016)

#112

Post by p_l »

jongjong wrote: post #71

Forcing all clients to reload their code at the same time sounds like a bad idea. Allowing different clients to run different incompatible versions of the code at the same time also sounds like a bad idea. APIs are like database engines; they should rarely change. Making it easy to change them is an anti-pattern. Engineers don't build bridges with replaceable pillars or skyscrapers with replaceable foundations. When…

737 MAX had nothing to do with replaceable engines, but with trying to run an ancient airframe with new engines but without necessary upgrades to support the new engines because of costs.

Re: Elixir/Erlang Hot Swapping Code (2016)

#113

Post by jongjong »

tzmudzin wrote: post #77
jongjong wrote: post #71

Forcing all clients to reload their code at the same time sounds like a bad idea. Allowing different clients to run different incompatible versions of the code at the same time also sounds like a bad idea. APIs are like database engines; they should rarely change. Making it easy to change them is an anti-pattern. Engineers don't build bridges with replaceable pillars or skyscrapers with replaceable foundations. When…

Engine replacement happens on airplanes fairly frequently. You don't want to scrap an airplane because of a single damaged turbine blade, or even keep it on the ground for longer. https://jalopnik.com/how-airlines-decide-to-replace-jet-engi... .

Yes but the new parts meet the specs of the original design. The design itself isn't flexible. You can't make the engines significantly bigger without significantly revising the blueprint as a whole. That was the Boeing Max lesson. Just changing the software was not enough.

Re: Elixir/Erlang Hot Swapping Code (2016)

#114

Post by jongjong »

p_l wrote: post #112
jongjong wrote: post #71

Forcing all clients to reload their code at the same time sounds like a bad idea. Allowing different clients to run different incompatible versions of the code at the same time also sounds like a bad idea. APIs are like database engines; they should rarely change. Making it easy to change them is an anti-pattern. Engineers don't build bridges with replaceable pillars or skyscrapers with replaceable foundations. When…

737 MAX had nothing to do with replaceable engines, but with trying to run an ancient airframe with new engines but without necessary upgrades to support the new engines because of costs.

Replaceable at the design level. OMG. Why do I have to explain everything? Clearly I'm talking about blueprints here. Code is a blueprint since you can launch multiple processes/instances running the same code.

Re: Elixir/Erlang Hot Swapping Code (2016)

#115

Post by p_l »

jongjong wrote: post #114
p_l wrote: post #112

Earlier quoted context omitted.

737 MAX had nothing to do with replaceable engines, but with trying to run an ancient airframe with new engines but without necessary upgrades to support the new engines because of costs.

Replaceable at the design level. OMG. Why do I have to explain everything? Clearly I'm talking about blueprints here. Code is a blueprint since you can launch multiple processes/instances running the same code.

And then you went and got even less on track, because offering multiple engines and re-engining aircraft is the norm, sometimes to very different engines (like Russian engines offered as upgrades to old Mirages)

Re: Elixir/Erlang Hot Swapping Code (2016)

#116

Post by bitwalker »

Muromec wrote: post #107
bitwalker wrote: post #106

Earlier quoted context omitted.

The example you've given here does not work the way you think it does. I would agree however that the mechanics of closure environments is simpler in Erlang due to the fact that values are immutable, as opposed to closures in other languages where mutability must be accounted for. I would also note that, for the example you've given, the compiler _could_ constant-fold the whole thing away, but for the sake of argumen…

> let's assume that `Val` is an argument to the current function in which `SumFun` is defined, and so the compiler cannot reason about the actual value that was bound. That was exactly the case I was talking about, because otherwise there is no need to even make arity 2 function. If the value is known at compile time, the constant is embedded into the body of inlined function. >At runtime, when the closure is execute…

> To my understanding, no it doesn't, as the value is resolved when the function pointed is created, not when the underlying function executes, which the code you linked shows too. I know it uses the "env" as a structure field, but it's partial application, not the actual closure which has access to parent scope

The code I linked literally shows that the closed-over terms are written into the closure environment when the fun is created, and if any term is a heap allocated object, it isn't copied into the closure, only the pointer is written into the env. The only reason you can't observe the effects of mutability here is because, unlike Python, there is no way to mutate bindings in Erlang.

Again, this isn't partial application - not in implementation nor in semantics.

Re: Elixir/Erlang Hot Swapping Code (2016)

#117

Post by jongjong »

p_l wrote: post #115
jongjong wrote: post #114

Earlier quoted context omitted.

Replaceable at the design level. OMG. Why do I have to explain everything? Clearly I'm talking about blueprints here. Code is a blueprint since you can launch multiple processes/instances running the same code.

And then you went and got even less on track, because offering multiple engines and re-engining aircraft is the norm , sometimes to very different engines (like Russian engines offered as upgrades to old Mirages)

Clearly there is a limit as to how different the engines can be in terms of size, weight, thrust, etc... Still if they want to add different engines, with different characteristics, they need to rerun all the calculations and tests to make sure it works with the frame, wings and everything else. No serious engineer outside of software realm aims to design silver bullet solutions. They always aim for a very specific solution.

If they need to adapt the solution later, they know it will involve a lot of re-working and require re-running all the calculations. This is fine. Nobody needs silver bullet solutions.

With software, if you design your API poorly and can't fix it in a backwards-compatible way, you can just release a new API version and migrate over to the new endpoints over time.

Re: Elixir/Erlang Hot Swapping Code (2016)

#118

Post by Muromec »

simoncion wrote: post #110
Muromec wrote: post #66

Earlier quoted context omitted.

>If we to wedge how Erlang does hot code swapping into a container metaphor, then to get what Erlang does, you'd need to have a container per function call. You have a container that responds to HTPP requests sitting behind a load balancer, then you spawn a new container and tell load balancer to redirect calls to the new one. From the point of view of whoever is calling the load balancer you have hot swapping. You m…

Sure, you can shut down and restart your entire application. You could do that back in 1990 without containers, too. The thing is that Erlang does hot reload at a per-function (or -according to Hebert- sometimes more-fine-grained) level, so nuking the entire program and paying the cost to start it up again is not at all the same thing as -say- using a not-absurdly-priced AWS Lambda [0] or similar to get per-function…

I didn't read that one before, but I share the sentiment. We can't have cool things and it was all dumbed down, so the worst case become a default mode of operation. This didn't happen specifically with hot reload in erlang, it happens all the time at all levels.

Re: Elixir/Erlang Hot Swapping Code (2016)

#119

Post by Muromec »

bitwalker wrote: post #116
Muromec wrote: post #107

Earlier quoted context omitted.

> let's assume that `Val` is an argument to the current function in which `SumFun` is defined, and so the compiler cannot reason about the actual value that was bound. That was exactly the case I was talking about, because otherwise there is no need to even make arity 2 function. If the value is known at compile time, the constant is embedded into the body of inlined function. >At runtime, when the closure is execute…

> To my understanding, no it doesn't, as the value is resolved when the function pointed is created, not when the underlying function executes, which the code you linked shows too. I know it uses the "env" as a structure field, but it's partial application, not the actual closure which has access to parent scope The code I linked literally shows that the closed-over terms are written into the closure environment when…

>Again, this isn't partial application - not in implementation nor in semantics.

Maybe you will change your opinion if you take a look at the code 'erlc -S' produces for the inline function.

Post reply on HN