3 ms·
To be fair though many Erlang programmers also avoid hot loading code. For the rest, nice summary.
by samvher 7y ago
To be fair though many Erlang programmers also avoid hot loading code. For the rest, nice summary.
- fouc 7y agoWhy would they avoid that? (hopefully it's not just because of the ease of containerization/docker that is leading to reduced hot loading)
- masklinn 7y ago> hopefully it's not just because of the ease of containerization/docker that is leading to reduced hot loading It's because it's not super easy to properly architect in, it's hard to test, and it requires supporting running multiple versions of the code concurrently (and the ability to migrate data on the fly).
- samvher 7y agoMainly because the relup functionality is a bit complicated and not always clear, Learn You Some Erlang explains some context [1]. It does depend a bit on the situation, in some cases it's easy to recompile a module in a running system and it might not be much of a problem. But when there are multiple modules being updated, which depend on each other, which possibly require updates to some data structures, it becomes very messy very quickly. Also when modules contain anonymous functions this can cause some issues (badfun errors) because the old version might get lost, but can still have references in the running system. [1] https://learnyousomeerlang.com/relups https://learnyousomeerlang.com/relups
- strmpnk 7y agoI’d not consider relup and module loading the same feature. It is rare to see relup (though I have used it, it’s tricky to make work) but hot code loading of modules was something we used extensively both during development but also in production to test out patches for problems. It was super easy to use and never a big problem. Keep in mind that we rolled out the patch incrementally to one or two machines and then to more. If it looked good we’d roll it out to the rest of the cluster. From there we’d make note of the result and get the change ported into a proper release. Each time I hear stories that both clustering and hot upgrades, module loading, etc are hard or rarely used I wonder if the person is just repeating someone else’s rumor. They’re great features and work fine if you do a little homework (just like learning anything, don’t treat it like magic). This was from my time at Cloudant/IBM, though its far from the only case I’ve seen. We ran over 1000 machines this way with some clusters growing to more than 200 nodes using distributed Erlang (something I keep hearing is hard or impossible, it’s not).
- samvher 7y agoNot sure if you're asking, but I'm not repeating someone else's rumor. I started the set-up I work with using hot loading (after all that is one of the things that attracts to Erlang) where I mean just reloading modules on the VM. Unfortunately I would get module order wrong from time to time or I would forget dependencies, and I've seen many badfun errors as well (I admit I used too many anonymous functions). With only 1 node doing the work (I haven't used Erlang on large clusters) that's a bit more risk and those problems have gone away completely since I switched to a strategy where the whole system just stops and starts.
- strmpnk 7y agoI see. Fair enough. It's definitely something I know can work but like most things it does take work and sometimes it's not worth the trade in effort for the capabilities one might gain otherwise. Badfun errors are a great example of something tricky if you're not used to thinking about how the compiler translates these to private functions via lambda lifting. It's the same reason funs are not something you should rush to pass around over a disterl cluster. Recursive functions which keep fun's around in a loop also become a problem if they're long lived. I usually point out that first class modules or MFA tuples are more idiomatic in Erlang than opaque first class functions as values but we're off into the weeds here. It's a good example of where effort and gotchas become a barrier for many.
- ramchip 7y agoIt’s rare in production, but fantastic in development. Often I don’t even restart my Elixir app when switching between git branches, because the hot reload is enough.