4 ms·

To add to this, it's worth noting that Elixir would have difficulty _ever_ becoming statically typed because of how message-passing works. For example, if you l

To add to this, it's worth noting that Elixir would have difficulty _ever_ becoming statically typed because of how message-passing works. For example, if you look at Gleam [0] -- the recent project that's trying to create a statically typed language for the BEAM -- it can't handle message-passing [1]. And I totally agree with you here: > I've found that it's possible to pretend it is a statically typed language if you squint just right. My Elixir code tends to use a lot of pattern matching on structs. It's not real static typing, but it gets me a lot of mileage! [0] https://gleam.run/index.html https://gleam.run/index.html [1] https://gleam.run/faqs.html#how-is-message-passing-typed https://gleam.run/faqs.html#how-is-message-passing-typed

QuinnWilton 6y ago
I don't know if I'd say "ever", but it definitely won't be easy! Take a look at session types [0] if you haven't seen them! Type checking unrestricted message passing would be difficult, but I can imagine a subset that's typeable. [0] http://groups.inf.ed.ac.uk/abcd/index.html#about http://groups.inf.ed.ac.uk/abcd/index.html#about
- scythmic_waves 6y ago
  I haven't seen them, thanks! > Type checking unrestricted message passing would be difficult, but I can imagine a subset that's typeable. I'd love to see a discussion on this somewhere. I can totally imagine a world where it's true that "yes, you can't send messages of type X because the receiver can't pattern match on them in the way you expect, but what you're really trying to do is Y, and you _can_ send messages of type Z that accomplish Y."
lpil 6y ago
Hi, I'm the author of Gleam. We have fully type safe message passing, we just don't have any special syntax for it. I'll update the documentation to make this clearer.
- scythmic_waves 6y ago
  Hi! Super cool project you've embarked on. I know everyone I work with (those who write Elixir, anyway) is very interested in its progress. > I'll update the documentation to make this clearer. Thanks! Much appreciated.
- steamboiler 6y ago
  Thanks for commenting. Do you have any code somewhere that demonstrates type-safe messages?
  - lpil 6y ago
    Certainly, there are some links to relevent libraries here -> https://gleam.run/faqs.html#how-is-message-passing-typed https://gleam.run/faqs.html#how-is-message-passing-typed
- steamboiler 6y ago
  Typing messages is considered a PhD (?) level problem. Could you talk more about how you went about solving it? Thanks!
  - lpil 6y ago
    It would be difficult (or perhaps impossible) to type all of Erlang's message passing features, so we reduced scope to not include distributed message passing or hot upgrades- so the types of all actors in the system can be known up front in order to be checked. In practice this is enough for the vast majority of applicatinos, and messages with runtime checks (like in regular Erlang) can be used for the other situations if required.
mercer 6y ago
I've heard a number of times that static typing would be near impossible for Erlang because of how message-passing works, but just the other day I read a quote where one of the creators (I think it was Joe Armstrong, but not completely certain) indicated that the primary reason they decided against static typing was the hot code reloading, not the feasibility. or not primarily anyways. Not disagreeing with you, I guess. It was just surprising/interesting to read. Sadly I can't find the quote...
- 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 ago
    Hi, 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 ago
      Not 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...

QuinnWilton 6y ago

I don't know if I'd say "ever", but it definitely won't be easy! Take a look at session types [0] if you haven't seen them! Type checking unrestricted message passing would be difficult, but I can imagine a subset that's typeable. [0] http://groups.inf.ed.ac.uk/abcd/index.html#about http://groups.inf.ed.ac.uk/abcd/index.html#about

scythmic_waves 6y ago
I haven't seen them, thanks! > Type checking unrestricted message passing would be difficult, but I can imagine a subset that's typeable. I'd love to see a discussion on this somewhere. I can totally imagine a world where it's true that "yes, you can't send messages of type X because the receiver can't pattern match on them in the way you expect, but what you're really trying to do is Y, and you _can_ send messages of type Z that accomplish Y."

lpil 6y ago

Hi, I'm the author of Gleam. We have fully type safe message passing, we just don't have any special syntax for it. I'll update the documentation to make this clearer.

scythmic_waves 6y ago
Hi! Super cool project you've embarked on. I know everyone I work with (those who write Elixir, anyway) is very interested in its progress. > I'll update the documentation to make this clearer. Thanks! Much appreciated.
steamboiler 6y ago
Thanks for commenting. Do you have any code somewhere that demonstrates type-safe messages?
- lpil 6y ago
  Certainly, there are some links to relevent libraries here -> https://gleam.run/faqs.html#how-is-message-passing-typed https://gleam.run/faqs.html#how-is-message-passing-typed
steamboiler 6y ago
Typing messages is considered a PhD (?) level problem. Could you talk more about how you went about solving it? Thanks!
- lpil 6y ago
  It would be difficult (or perhaps impossible) to type all of Erlang's message passing features, so we reduced scope to not include distributed message passing or hot upgrades- so the types of all actors in the system can be known up front in order to be checked. In practice this is enough for the vast majority of applicatinos, and messages with runtime checks (like in regular Erlang) can be used for the other situations if required.

mercer 6y ago

I've heard a number of times that static typing would be near impossible for Erlang because of how message-passing works, but just the other day I read a quote where one of the creators (I think it was Joe Armstrong, but not completely certain) indicated that the primary reason they decided against static typing was the hot code reloading, not the feasibility. or not primarily anyways. Not disagreeing with you, I guess. It was just surprising/interesting to read. Sadly I can't find the quote...

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 ago
  Hi, 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 ago
    Not 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...