3 ms·

How does one avoid type errors in Erlang applications? If the answer is 'testing' then types are indeed an obvious gap in the language. If it's something else,

How does one avoid type errors in Erlang applications? If the answer is 'testing' then types are indeed an obvious gap in the language. If it's something else, I'm genuinely interested to know. What makes Erlang so special that a lack of types actually aids (or at least does not at all hinder) in long-term maintenance/refactoring or enforcing type-level constraints on values?

filmor 6y ago
Erlang doesn't lack types. It's also strongly typed. You can get quite far with properly chosen guard expressions (`is_binary`, `is_number`), general pattern matching and Dialyzer to check what's checkable. Static typing severely hinders hot code-reload, which was deemed more important for long running systems.
- loxs 6y ago
  These are runtime checks and have nothing to do with what most people understand under the term "static typing/types".
  - igouy 6y ago
    Dialyzer is a static analysis tool. https://erlang.org/doc/man/dialyzer.html https://erlang.org/doc/man/dialyzer.html
    - loxs 6y ago
      It is, but is_number is not, which I am replying to. Probably should have mentioned, my bad...
  - filmor 6y ago
    Just to be clear, I intentionally never said anything about static types. The type system is "strong" in the sense that variables never change their type or are "interpreted" based on context, they don't even change their value after assignment. And whether your types are runtime-checked or statically checked doesn't really matter with regard to the invariants that hold for your code. In the former case, you'll have to be able to handle type errors at runtime as well, which is reasonably easy in Erlang due to the strong isolation it provides.
loxs 6y ago
After many conversations on the topic with good to great Erlang programmers (I also have 7 years of experience under my belt) I come to the conclusion that they just "don't get it". Probably there is a subset of extremely smart people who can write good and very reliable software in a dynamic language without going mad, but I am not among them. In the end I just left the language and now I am much happier with a mix of TypeScript, OCaml and Rust Also the reliability they are talking about is quite different from the reliability that most people (especially ones who have not worked on erlang-y systems) think of when they hear the word. The Erlang reliability is about finding bugs and patching them (often in production) and not about avoiding them in the first place. Also it's about avoiding total system failure because of some bug in a part in it. This is a nice to have thing in all systems, but Erlang makes it easier to implement. Of course, they also like to avoid bugs, but for that they use testing. And of course, we have to mention dialyzer which is something like TypeScript for Erlang but a lot less polished and with practically no tooling support. It is used in every significant Erlang project but the process is IMO quite sub-optimal and the price you pay (in suffering) is quite high.
- coldcode 6y ago
  I've never worked in Erlang, but I did use Objective-C for a long time, and switched to Swift almost 5 years ago. Strong types makes it massively easier to ship high quality applications, while I could do so in the C variant it took a lot more effort and testing. In Swift I can make the language make it almost impossible to create erroneous code. It's not that you can't make good code in any language, but the cost is often not worth it; anything that makes it easier and more reliable saves you time and effort in the long run.
  - Multicomp 6y ago
    Your last paragraph is why I enjoy F# and rust as much as I do. If the computer can do more to help you make illegal States unrepresentable then why not let it? Hence I am waiting on Gleam before I invest in Erlangy stuff. In the meantime I will explore the actor model of concurrency with F# Mailboxes.
andrenth 6y ago
Pattern matching and immutability help a lot in practice, even with dynamic types.
- loxs 6y ago
  Absolutely. Somebody, somewhere used to say that Erlang is neither static, nor dynamic typing, but somewhere in the middle. I can agree to a large degree.
didibus 6y ago
> If the answer is 'testing' then types are indeed an obvious gap in the language Will you not be testing your code anyways? Will you not have unit tests and integ tests and have it run in a devo environment first? Before going to production? If so, then what would the gap be? If you catch those same type errors as you test, and you will be testing anyways?
- loxs 6y ago
  Depending on the project, I have (not) done all of these and given adequate system (mostly types) design, it's been absolutely OK.
- lttlrck 6y ago
  Surely catching the errors early is a benefit, or are all typed languages doing it wrong?
  - didibus 6y ago
    Is your argument for it being a benefit that there are lots of languages doing so? Cause there's just as many dynamic languages not doing so, so I'm not sure this argument takes us anywhere.
toast0 6y ago
> How does one avoid type errors in Erlang applications? When I write Erlang, I'm not necessarily concerned with avoiding errors. The philosophy of the system is that errors will occur, and the focus is on making sure errors do not compound into system failure (supervision tree helps with this), that they're easy to see (appropriate logging of crashes), and that it's easy to deploy fixes (hotloading). I'm sure there are many ways to avoid some errors in production, but more focus is on responding to errors than on preventing them. At least in my experience.

filmor 6y ago

Erlang doesn't lack types. It's also strongly typed. You can get quite far with properly chosen guard expressions (`is_binary`, `is_number`), general pattern matching and Dialyzer to check what's checkable. Static typing severely hinders hot code-reload, which was deemed more important for long running systems.

loxs 6y ago
These are runtime checks and have nothing to do with what most people understand under the term "static typing/types".
- igouy 6y ago
  Dialyzer is a static analysis tool. https://erlang.org/doc/man/dialyzer.html https://erlang.org/doc/man/dialyzer.html
  - loxs 6y ago
    It is, but is_number is not, which I am replying to. Probably should have mentioned, my bad...
- filmor 6y ago
  Just to be clear, I intentionally never said anything about static types. The type system is "strong" in the sense that variables never change their type or are "interpreted" based on context, they don't even change their value after assignment. And whether your types are runtime-checked or statically checked doesn't really matter with regard to the invariants that hold for your code. In the former case, you'll have to be able to handle type errors at runtime as well, which is reasonably easy in Erlang due to the strong isolation it provides.

loxs 6y ago

After many conversations on the topic with good to great Erlang programmers (I also have 7 years of experience under my belt) I come to the conclusion that they just "don't get it". Probably there is a subset of extremely smart people who can write good and very reliable software in a dynamic language without going mad, but I am not among them. In the end I just left the language and now I am much happier with a mix of TypeScript, OCaml and Rust Also the reliability they are talking about is quite different from the reliability that most people (especially ones who have not worked on erlang-y systems) think of when they hear the word. The Erlang reliability is about finding bugs and patching them (often in production) and not about avoiding them in the first place. Also it's about avoiding total system failure because of some bug in a part in it. This is a nice to have thing in all systems, but Erlang makes it easier to implement. Of course, they also like to avoid bugs, but for that they use testing. And of course, we have to mention dialyzer which is something like TypeScript for Erlang but a lot less polished and with practically no tooling support. It is used in every significant Erlang project but the process is IMO quite sub-optimal and the price you pay (in suffering) is quite high.

coldcode 6y ago
I've never worked in Erlang, but I did use Objective-C for a long time, and switched to Swift almost 5 years ago. Strong types makes it massively easier to ship high quality applications, while I could do so in the C variant it took a lot more effort and testing. In Swift I can make the language make it almost impossible to create erroneous code. It's not that you can't make good code in any language, but the cost is often not worth it; anything that makes it easier and more reliable saves you time and effort in the long run.
- Multicomp 6y ago
  Your last paragraph is why I enjoy F# and rust as much as I do. If the computer can do more to help you make illegal States unrepresentable then why not let it? Hence I am waiting on Gleam before I invest in Erlangy stuff. In the meantime I will explore the actor model of concurrency with F# Mailboxes.

andrenth 6y ago

Pattern matching and immutability help a lot in practice, even with dynamic types.

loxs 6y ago
Absolutely. Somebody, somewhere used to say that Erlang is neither static, nor dynamic typing, but somewhere in the middle. I can agree to a large degree.

didibus 6y ago

> If the answer is 'testing' then types are indeed an obvious gap in the language Will you not be testing your code anyways? Will you not have unit tests and integ tests and have it run in a devo environment first? Before going to production? If so, then what would the gap be? If you catch those same type errors as you test, and you will be testing anyways?

loxs 6y ago
Depending on the project, I have (not) done all of these and given adequate system (mostly types) design, it's been absolutely OK.
lttlrck 6y ago
Surely catching the errors early is a benefit, or are all typed languages doing it wrong?
- didibus 6y ago
  Is your argument for it being a benefit that there are lots of languages doing so? Cause there's just as many dynamic languages not doing so, so I'm not sure this argument takes us anywhere.

toast0 6y ago

> How does one avoid type errors in Erlang applications? When I write Erlang, I'm not necessarily concerned with avoiding errors. The philosophy of the system is that errors will occur, and the focus is on making sure errors do not compound into system failure (supervision tree helps with this), that they're easy to see (appropriate logging of crashes), and that it's easy to deploy fixes (hotloading). I'm sure there are many ways to avoid some errors in production, but more focus is on responding to errors than on preventing them. At least in my experience.