himaraya
Hot reloading and static types
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.
Edit: Another thread mentions other obstacles including backwards compatibility to statically typed Elixir. I also came across Elchemy, which doesn’t seem production ready. Thoughts appreciated!
Most Liked
lpil
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
GitHub - gleam-lang/gleam: ⭐️ A friendly language for building type-safe, scalable systems! · GitHub
For more info on the work at Facebook the keynote from Simon Marlow at this year’s Haskell exchange was very informative.
lpil
Elchemy is an alternatively compiler for the Elm programming language that outputs Elixir rather than Javascript, Gleam is an entirely new language.
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.
Other projects worth checking out are the Alpaca language GitHub - alpaca-lang/alpaca: Functional programming inspired by ML for the Erlang VM · GitHub and the Purescript to Erlang compiler GitHub - purerl/purescript: A small strongly typed language that compiles to Erlang (not JavaScript) · GitHub
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









