7 ms·
I'm the author of Gleam, a statically typed language on the BEAM. What you've said matches my findings. Messages can be typed, however hot code upgrades cannot
by lpil 6y ago
I'm the author of Gleam, a statically typed language on the BEAM.
What you've said matches my findings. Messages can be typed, however hot code upgrades cannot be. For Gleam we've sacrified hot code loading in exchange for types, which I think is a good trade for most use cases.
- lukevp 6y agoHi, thank you for contributing! I have gotten into the functional programming paradigm conceptually from working with react/redux. We do all of our development work using TypeScript, rather than JavaScript. Typescript isn’t really static typing, but more like type assertions on top of a dynamic language, but hot reloading works fine and is a core component of the workflow, especially with the ability to maintain state in between loads. I’m new to this world and haven’t yet tried Elixir, but what is it about the type system that prevents hot reloading? Is it because the underlying execution system is using types for something? Could a typescript-style language be built on top of Elixir and BEAM that would allow hot reloading and type assertions together?
- thomasfortes 6y agoNot touching on the reasons why the type system and hot code reloading are complex in the BEAM, but the hot code reloading dev workflows in other languages and the BEAM one are two completely different beasts. Erlang/OTP was designed for systems where the amount of acceptable downtime is 0, you don't want phone calls failing because you have to fix a bug, the solution is a system where you can replace parts of it running live, if you replace a module all processes currently running it will still work normally but any new call to the module will use the updated version of it. https://blog.appsignal.com/2018/10/16/elixir-alchemy-hot-code-reloading-in-elixir.html https://blog.appsignal.com/2018/10/16/elixir-alchemy-hot-cod...
- lpil 6y agoThe hot loading of code we're talking about is mutating of running code in production, and it involves running multiple different versions of the same code at the same time in order to do a clean and incremental migration to the new version while continuing to serve traffic. It's a different set of constraints to hot loading JavaScript style and very difficult to get right. The nation problem is that you don't have any way of knowing what the the state of the running system is (it is mutable) so you cannot unify your new types with the existing system. We could probably do hot loading in development using type assertions fairly happily.
- lukevp 6y agoI see, thank you for the response. I haven’t ever heard of something like this being possible in production. We typically have to do phased rollouts at a different level of the stack, it’s not something supported by the runtime!
- lpil 6y agoIt came from Ericsson needing to upgrade telephone switch firmware without taking the system down. These telephone switches were often expensive and in physically difficult to reach places so having a standby for a switch-over wasn't viable. Quite an interesting set of constraints!
- gilmi 6y agoI'd really like to read about your finding wrt hot code loading. Is there anything you can point me to?