5 ms·

There's a difference between a linter that's capable of catching some type errors and a full modern static type system. Compare e.g. MyPy with TypeScript. Dialy

There's a difference between a linter that's capable of catching some type errors and a full modern static type system. Compare e.g. MyPy with TypeScript. Dialyser reduces runtime type errors; a full type system can eliminate them.

jakear 7y ago
Wait does Erlang not have type soundness?
- knome 7y ago
  erlang is typed like python is typed. dynamic strong types. it has a static analyzer that will catch mistakes if you add the appropriate type annotations, however.
  - jakear 7y ago
    Huh. TIL. To be honest I always associated functional programming with sound type inference, a. la. Hindley-Milner. (my Haskell background is leaking). Would you happen to know the rationale behind it being unsound?
    - dnautics 7y ago
      Hot code reloading and message passing across networks is just easier without it. I can take any erlang term (including lambdas), pickle it, write down the bytes, put it on a carrier pigeon, unpickle it on the other side and it will become the corresponding term on the other side.
fendy3002 7y ago
In this case does typescript fit into modern static type system?
toast0 7y ago
The nature of BEAM as a distributed system makes it hard to guarantee anything. If another node running code outside your analysis set sends you a message you can't know what it will be at analysis time. There could be many reasons for the sending code to be outside your analysis set. The sending code could be in another distinct code module (perhaps in a 3rd party library). The sending node may be running an older version of the code. The sending node may be running a newer version of the code. Something terrible could have happened on the sending node.
- kilburn 7y ago
  I don't see how this is different than any other IO in most systems today. For instance, the moment you make an http request you can't possibly know for sure what kind of response you'll get back. However, you can strongly type your way from "string of bytes" all the way to "a Pet record" by parsing, and the calling side just receives a strongly typed result on the lines of "Result<Pet, Error>". Why couldn't you do the same thing in BEAM?
  - dnautics 7y ago
    It's not that simple. What if the sending process is a human operator trying to introspect your system with a remote console, and a slightly misspelled token is sent? What is the right thing to do? Drop the message? Crash? Sometimes one thing is the right thing to do and sometimes the other. But messages are such a low level concept in erlang... It's really hard to make a strongly typed system that doesn't pick one over the other, which is going to be the wrong answer half the time. I'm not saying it can't be done, but many have tried and no one has succeeded yet.
    - zachrose 7y ago
      I believe the right thing to do is to parse the response “into” an error and pass it to the error-handling branch that your compiler required when the handler was written. Or at least, that’s how it works in the statically typed language Elm, which guarantees that your compiled code will not throw any runtime errors.

jakear 7y ago

Wait does Erlang not have type soundness?

knome 7y ago
erlang is typed like python is typed. dynamic strong types. it has a static analyzer that will catch mistakes if you add the appropriate type annotations, however.
- jakear 7y ago
  Huh. TIL. To be honest I always associated functional programming with sound type inference, a. la. Hindley-Milner. (my Haskell background is leaking). Would you happen to know the rationale behind it being unsound?
  - dnautics 7y ago
    Hot code reloading and message passing across networks is just easier without it. I can take any erlang term (including lambdas), pickle it, write down the bytes, put it on a carrier pigeon, unpickle it on the other side and it will become the corresponding term on the other side.

fendy3002 7y ago

In this case does typescript fit into modern static type system?

toast0 7y ago

The nature of BEAM as a distributed system makes it hard to guarantee anything. If another node running code outside your analysis set sends you a message you can't know what it will be at analysis time. There could be many reasons for the sending code to be outside your analysis set. The sending code could be in another distinct code module (perhaps in a 3rd party library). The sending node may be running an older version of the code. The sending node may be running a newer version of the code. Something terrible could have happened on the sending node.

kilburn 7y ago
I don't see how this is different than any other IO in most systems today. For instance, the moment you make an http request you can't possibly know for sure what kind of response you'll get back. However, you can strongly type your way from "string of bytes" all the way to "a Pet record" by parsing, and the calling side just receives a strongly typed result on the lines of "Result<Pet, Error>". Why couldn't you do the same thing in BEAM?
- dnautics 7y ago
  It's not that simple. What if the sending process is a human operator trying to introspect your system with a remote console, and a slightly misspelled token is sent? What is the right thing to do? Drop the message? Crash? Sometimes one thing is the right thing to do and sometimes the other. But messages are such a low level concept in erlang... It's really hard to make a strongly typed system that doesn't pick one over the other, which is going to be the wrong answer half the time. I'm not saying it can't be done, but many have tried and no one has succeeded yet.
  - zachrose 7y ago
    I believe the right thing to do is to parse the response “into” an error and pass it to the error-handling branch that your compiler required when the handler was written. Or at least, that’s how it works in the statically typed language Elm, which guarantees that your compiled code will not throw any runtime errors.