Just FYI, if you want to play with something like the BEAM that has types, you might enjoy a look at Pony. This talk compares the two approaches, which did help me understand some of the tradeoffs.
JEG2
Author of Designing Elixir Systems with OTP
rvirding
Creator of Erlang
I just want to confirm what has already been mentioned a number of times in this thread: the reason for not having static typing in Erlang was the absolute need for doing dynamic code upgrades of running systems. This was an absolute requirement and if we couldn’t do it then our language/system wasn’t interesting. There aren’t many systems using it today as most try to do rolling upgrades but we didn’t have that option back then so we had to be able to upgrade a running system. Remember we are talking late 80’s early 90’s here.
Some evil tongues says it because we didn’t know how to write type-checking systems but that is totally ridiculous. As we had taught ourselves to write compilers, and done a number of them, to implement virtual machines, and done a number of them, and to implement run-time and os-like systems, and done a number of them as well, then implementing type-checking would not have been especially difficult. It’s not rocket science and it wasn’t then either. Just RTFM.
Whether you like dynamic typing or prefer static typing that is a matter of choice but as I have said for us it was not an option.
On a side note I would say probably the main difficulty with implementing a statically typed language on top of erlang/OTP/BEAM is interfacing to the world outside. I mean you can call any function with any arguments and send any message to any process so the problem how do I make the statically typed part of the system “safe”. And no, processes can’t hide either as with the Process.list/processes built-in functions I can see all processes.
A final note: Erlang/elixir/BEAM is actually strongly typed but dynamically typed not statically typed. If we want to be picky.
53
ityonemo
There aren’t many systems using [hot code reloading] today…
I may be mistaken but I believe Phoenix live reload uses erlang’s hot code reloading, in which case upwards of 70-80% of the people on this forum are using hot code reloading, even if they don’t know it.
0
mkunikow
The Typescript is example how OO people (Microsoft ) design types …
If I want good type system for JS I would go for Reason ML https://reasonml.github.io/
The Beam hot reloading was designed not for static typed langue
If I want good static typed type system I prefer langue that was implemented for types from ground up …
0
egze
Phoenix code reloader is different. It just watches for changes and recompiles the files. Then after browser refresh, you have the latest compiled code for your request.
1
rvirding
Creator of Erlang
Wouldn’t that become rather heavy if it is checking for every request. How does it reload the the recompiled modules? Is it just loading them in or is it using some mechanism like OTPs code_change callback to allow old version to “migrate” to new version?
OTP purposely does not have some mechanism to check code and automatically recompile and reload. Apart from the extra load in doing this (when would you do it?) the system might have/probably will have special requirements when upgrading code.
0
egze
I think it‘s not heavy to recompile a couple if changed modules. This is also only in dev environment.
I don‘t see any code_change stuff in there, so I guess it‘s just recompile and that‘s it. Maybe someone else more knowledgeable can share some details?
0
tmbb
AFAIK, the code reloader simply recompiles modules in files that have been changed (and their compile time dependents) and reloads the current page so that it reflects the changed code. It does not update your genserver state.
0
ityonemo
lpil
Creator of Gleam
Are you sure? I would have expected it to use the normal OTP code upgrading features, and OTP uses the code_change callback to update the state of a gen_server.
0