I read this thread from last year and got curious about the mentioned black-boxing “fix” for hot reloading with static types. How feasible is it? I read that a statically typed version of Erlang was abandoned years ago due to speed and complexity concerns.
At Facebook they actually do hot code swapping of Haskell, which is a statically typed language.
The rules they follow is that the swapped in object code must export functions of the same type as the previous version. There is nothing checking these types are correct other than human testing, so it’s effectively dynamically typed at this point.
Alternatively we could define an opaque “any” type and force the user to safely decode their data on code change. This isn’t an option for Haskell as their runtime needs to know the memory layout of the data as it is not designed for dynamic data.
I could imagine a system like this working for a typed Erlang. If I might self publicise a little, I’m working on a typed language for the Erlang VM at the moment, and I plan to experiment with this here https://github.com/lpil/gleam
For more info on the work at Facebook the keynote from Simon Marlow at this year’s Haskell exchange was very informative.
Thanks! I just came across Elchemy – how’s Gleam different?
The most obvious differences between Gleam and Elm are that Gleam has side effects, Elm does not, Elm has autocurrying, Gleam does not, Elm has a Haskell like syntax, Gleam has a Rust like syntax, and Gleam has a slightly more expressive (though unfinished) type system as it has typed modules. Elm’s compiler is written in Haskell, Elchemy’s compiler is written in Elm, Gleam’s compiler is written in Rust. Both languages are relatively simple functional programming languages that prioritise safety and clarity.
Elm and Elchemy are more mature than Gleam (which isn’t use useable currently). Gleam was designed to be a BEAM language while Elm was not- because of this I think that once ready Gleam will more suited to writing Erlang/Elixir style OTP programs than Elchemy is, though that’s possibly my personal bias.
It’s interesting to note that in Haskell, there is a library to facilitate upgradable types, called SafeCopy, which is used in some systems, but it does not seem to be entirely painless:
From user ‘Mightybyte’ on the Haskell ∪ Chat Discord group:
Another problem with that approach is that it depends on the old version being known. If you write the incorrect type there or the update is applied to a node running different code to what you expect then your upgrade will fail and likely lose state.