9 ms·

Why do you want that? Interestingly, Joe Armstrong said that people always asked about a static type system, but he couldn’t figure out the value of them. They

Why do you want that? Interestingly, Joe Armstrong said that people always asked about a static type system, but he couldn’t figure out the value of them. They were able to build extremely reliable systems with Erlang’s existing type system. And he mentioned at least one project that was 2 million LOC, so these weren’t just toy projects. So what are you unable to accomplish in Erlang that makes you feel like it’s missing something?

rkangel 6y ago
"Is possible to do" isn't the same as "helps you to so". You can write extremely reliable code in C (e.g. medical devices and car ECUs) but you have to be vary careful with any concurrency and usually dynamic memory allocation is banned. An enormous amount of testing and other design rules are needed. Maybe Rust would help to automatically check some of those things that otherwise require a lot of work to achieve. You can write highly concurrent server applications in C. It's a lot of work and bug prone. If you write them in Elrnag or Elixir your life will be much easier. That's why we use them. Maybe a static type system would help enforce some invariants about your code. Maybe it saves you from witting some classes of test. Basically, maybe you get to the same endpoint but with less work.
- romanoderoma 6y ago
  > "Is possible to do" isn't the same as "helps you to so" The things that help you usually also limit you See: training wheels or armbands I've seen much code written in static typed languages (mostly JVM languages) that supposedly help the programmer to write better code or code with less errors just by playing tennis with the compiler Thruth is that most of the code I've seen written "with type aids" is terrible from any other point of view The types are correctly passed to each function, but what purpose those types serve it's a mistery When you only have numbers, binaries, lists and tuples,you are forced to think about data structures in a simpler and more elegant way IDE generated "type safe" code too often is simply "a class for everything" and bad abstractions Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each?
  - m45t3r 6y ago
    > Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each? This is the fault of the language or programmer itself instead of its type system. I am programming in Dart and sometimes I feel that I am writing some code just to workaround some limitations in the language (the language itself is nice 90% of time, just to make it clear). Now, I also program in Python using mypy, and I never needed to write "10 getters and setters" to make the compiler happy. Sometimes I do need to write additional code to make mypy happy, but generally it is in overly clever code that mypy doesn't understand. So generally fixing the issues makes the code better.
    - romanoderoma 6y ago
      > This is the fault of the language or programmer itself instead of its type system. Not that I disagree, but I argue that bad programmers are the result of bad languages enabling them and bad use of types by the programmers is the result of a bad implementation of types in the language. Most of the statically typed languages around are used to enforce conventions inside large teams of coders, they are not used to "model the problem elegantly". If type driven development really produced bug free code while requiring the same cognitive load as hammering tens of lines of code one after the other, we will all be using something like Idris.
      - m45t3r 6y ago
        > Most of the statically typed languages around are used to enforce conventions inside large teams of coders This is not the fault of the type system though. It is the fault of things like enforcing access via private/protected/public keywords. While most people confuse this with a static type system, this is not part of the type system. > [..] they are not used to "model the problem elegantly". I concur, but let me make my point more clearly: this is either the fault of the language for not allowing the programmer to express itself clearly, or it is the fault of the programmer by using patterns from a less expressive programming language in a more expressive programming language. This is not the fault of the type system, that doesn't (by itself) require the user to create a Class with getters and setters for every attribute, for example. If the language you're using makes you do those kinda of things, it is the problem with the language itself, the type system is just the point of the iceberg (that is making the problem worse). > If type driven development really produced bug free code while requiring the same cognitive load as hammering tens of lines of code one after the other, we will all be using something like Idris. It doesn't produce bug free code (because there is still logic bugs), but it helps to reduce the number of bugs. But only in expressive type systems that are also sound. The Java type system for example doesn't help much (however I think they implemented nullables at some point, so the situation should be better).
- amw-zero 6y ago
  He found that Erlang (and to a large extent OTP) certainly "helped" to write reliable code, it didn't just "make it possible."
brightball 6y ago
From the conversations that I have seen, it seems to just be a comfort level thing. I haven’t seen many strong arguments for it other than “I want it because it helps me a lot in other languages.” The benefit just isn’t that prominent in a system built for the BEAM from what I’ve seen. And there are a bunch of negative trade offs that make distribution and hot reloading a lot more complicated.
giantDinosaur 6y ago
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.
StreamBright 6y ago
The biggest use of the static type system to me is development efficiency. I can write type safe code much faster than I can write duck typing code. Examples: - I accidentally pass in 3 params instead of 4 to a function (with static typing this does not compile) - I forgot to handle an edge case (I can use a discriminated unions for example to handle all cases explicitly) - I did not check if something was null and pass it in to a function (does not happen in most ML languages) I know that you can have editor plugins to handle these, still. I can develop reliable code much faster in F# than in Clojure, even though I love Clojure to death. You can do many things in Erlang that helps with these, still it would be really good to have a language that unifies Erlang and ML (any ML with Hindley–Milner type system would work).
- lostcolony 6y ago
  - I accidentally pass in 3 params instead of 4 to a function (with static typing this does not compile) In Erlang this will also not compile, unless you have a 3 parameter version of the function, in which case static typing will not help you. - I forgot to handle an edge case (I can use a discriminated unions for example to handle all cases explicitly) You also forgot to write a test it sounds like. And if it affects your production code, you also forgot to think through your supervisor restart strategy. - I did not check if something was null and pass it in to a function (does not happen in most ML languages) Null isn't a special thing in Erlang. You can have the atom 'null' or 'undefined' or whatever, but that's an intentional assignment you create. And given the single assignment immutable nature of Erlang, you won't accidentally be setting/leaving things set to 'null'.
  - Multicomp 6y ago
    I am not GP. > unless you have a 3 parameter version of the function, in which case static typing will not help you I half disagree. Let's say we go with the above scenario. If you have a three parameter function, static typing adds a check that the input parameter types need to match, if they don't, the program will not compile. Additionally, the returned type of the function may also not match, which would also be caught by the compiler, and depending on when the developer is writing the code, maybe immediately by the developer noticing that the type signature of the function does not match what they expect. With dynamic typing, those checks have to happen at runtime or as a human written test. But if the compiler is smart enough to do it automatically, why not use that? > You also forgot to write a test it sounds like. And if it affects your production code, you also forgot to think through your supervisor restart strategy. Programming languages like F# have exhaustive pattern matching, which obviates the need for testing on whether all cases of a union type have been matched, because if they haven't, the compiler will emit a warning or error depending on one's language server settings. Whichever setting is used, the developer immediately knows they are missing a pattern match case at compile time. >ngiven the single assignment immutable nature of Erlang, you won't accidentally be setting/leaving things set to 'null'. This is similar to ml languages like F#. They are also immutable by default. F# calls it "unit".
higerordermap 6y ago
If nothing, it is great for IDE support and refactoring.
dudul 6y ago
Static typing is very useful to write self-documenting code.
bcardarella 6y ago
The desire for a strong type system in Erlang/Elixir for me is more about tooling. Getting the types leads to better tools and that will lead to a better developer experience.

rkangel 6y ago

"Is possible to do" isn't the same as "helps you to so". You can write extremely reliable code in C (e.g. medical devices and car ECUs) but you have to be vary careful with any concurrency and usually dynamic memory allocation is banned. An enormous amount of testing and other design rules are needed. Maybe Rust would help to automatically check some of those things that otherwise require a lot of work to achieve. You can write highly concurrent server applications in C. It's a lot of work and bug prone. If you write them in Elrnag or Elixir your life will be much easier. That's why we use them. Maybe a static type system would help enforce some invariants about your code. Maybe it saves you from witting some classes of test. Basically, maybe you get to the same endpoint but with less work.

romanoderoma 6y ago
> "Is possible to do" isn't the same as "helps you to so" The things that help you usually also limit you See: training wheels or armbands I've seen much code written in static typed languages (mostly JVM languages) that supposedly help the programmer to write better code or code with less errors just by playing tennis with the compiler Thruth is that most of the code I've seen written "with type aids" is terrible from any other point of view The types are correctly passed to each function, but what purpose those types serve it's a mistery When you only have numbers, binaries, lists and tuples,you are forced to think about data structures in a simpler and more elegant way IDE generated "type safe" code too often is simply "a class for everything" and bad abstractions Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each?
- m45t3r 6y ago
  > Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each? This is the fault of the language or programmer itself instead of its type system. I am programming in Dart and sometimes I feel that I am writing some code just to workaround some limitations in the language (the language itself is nice 90% of time, just to make it clear). Now, I also program in Python using mypy, and I never needed to write "10 getters and setters" to make the compiler happy. Sometimes I do need to write additional code to make mypy happy, but generally it is in overly clever code that mypy doesn't understand. So generally fixing the issues makes the code better.
  - romanoderoma 6y ago
    > This is the fault of the language or programmer itself instead of its type system. Not that I disagree, but I argue that bad programmers are the result of bad languages enabling them and bad use of types by the programmers is the result of a bad implementation of types in the language. Most of the statically typed languages around are used to enforce conventions inside large teams of coders, they are not used to "model the problem elegantly". If type driven development really produced bug free code while requiring the same cognitive load as hammering tens of lines of code one after the other, we will all be using something like Idris.
    - m45t3r 6y ago
      > Most of the statically typed languages around are used to enforce conventions inside large teams of coders This is not the fault of the type system though. It is the fault of things like enforcing access via private/protected/public keywords. While most people confuse this with a static type system, this is not part of the type system. > [..] they are not used to "model the problem elegantly". I concur, but let me make my point more clearly: this is either the fault of the language for not allowing the programmer to express itself clearly, or it is the fault of the programmer by using patterns from a less expressive programming language in a more expressive programming language. This is not the fault of the type system, that doesn't (by itself) require the user to create a Class with getters and setters for every attribute, for example. If the language you're using makes you do those kinda of things, it is the problem with the language itself, the type system is just the point of the iceberg (that is making the problem worse). > If type driven development really produced bug free code while requiring the same cognitive load as hammering tens of lines of code one after the other, we will all be using something like Idris. It doesn't produce bug free code (because there is still logic bugs), but it helps to reduce the number of bugs. But only in expressive type systems that are also sound. The Java type system for example doesn't help much (however I think they implemented nullables at some point, so the situation should be better).
amw-zero 6y ago
He found that Erlang (and to a large extent OTP) certainly "helped" to write reliable code, it didn't just "make it possible."

brightball 6y ago

From the conversations that I have seen, it seems to just be a comfort level thing. I haven’t seen many strong arguments for it other than “I want it because it helps me a lot in other languages.” The benefit just isn’t that prominent in a system built for the BEAM from what I’ve seen. And there are a bunch of negative trade offs that make distribution and hot reloading a lot more complicated.

giantDinosaur 6y ago

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.

StreamBright 6y ago

The biggest use of the static type system to me is development efficiency. I can write type safe code much faster than I can write duck typing code. Examples: - I accidentally pass in 3 params instead of 4 to a function (with static typing this does not compile) - I forgot to handle an edge case (I can use a discriminated unions for example to handle all cases explicitly) - I did not check if something was null and pass it in to a function (does not happen in most ML languages) I know that you can have editor plugins to handle these, still. I can develop reliable code much faster in F# than in Clojure, even though I love Clojure to death. You can do many things in Erlang that helps with these, still it would be really good to have a language that unifies Erlang and ML (any ML with Hindley–Milner type system would work).

lostcolony 6y ago
- I accidentally pass in 3 params instead of 4 to a function (with static typing this does not compile) In Erlang this will also not compile, unless you have a 3 parameter version of the function, in which case static typing will not help you. - I forgot to handle an edge case (I can use a discriminated unions for example to handle all cases explicitly) You also forgot to write a test it sounds like. And if it affects your production code, you also forgot to think through your supervisor restart strategy. - I did not check if something was null and pass it in to a function (does not happen in most ML languages) Null isn't a special thing in Erlang. You can have the atom 'null' or 'undefined' or whatever, but that's an intentional assignment you create. And given the single assignment immutable nature of Erlang, you won't accidentally be setting/leaving things set to 'null'.
- Multicomp 6y ago
  I am not GP. > unless you have a 3 parameter version of the function, in which case static typing will not help you I half disagree. Let's say we go with the above scenario. If you have a three parameter function, static typing adds a check that the input parameter types need to match, if they don't, the program will not compile. Additionally, the returned type of the function may also not match, which would also be caught by the compiler, and depending on when the developer is writing the code, maybe immediately by the developer noticing that the type signature of the function does not match what they expect. With dynamic typing, those checks have to happen at runtime or as a human written test. But if the compiler is smart enough to do it automatically, why not use that? > You also forgot to write a test it sounds like. And if it affects your production code, you also forgot to think through your supervisor restart strategy. Programming languages like F# have exhaustive pattern matching, which obviates the need for testing on whether all cases of a union type have been matched, because if they haven't, the compiler will emit a warning or error depending on one's language server settings. Whichever setting is used, the developer immediately knows they are missing a pattern match case at compile time. >ngiven the single assignment immutable nature of Erlang, you won't accidentally be setting/leaving things set to 'null'. This is similar to ml languages like F#. They are also immutable by default. F# calls it "unit".

higerordermap 6y ago

If nothing, it is great for IDE support and refactoring.

dudul 6y ago

Static typing is very useful to write self-documenting code.

bcardarella 6y ago

The desire for a strong type system in Erlang/Elixir for me is more about tooling. Getting the types leads to better tools and that will lead to a better developer experience.