4 ms·

Erlang already has dialyzer. Are they making another dialyzer?

WilliamEdward 7y ago
If this was true, i suspect theirs would be better. Dialyzer doesn't seem very interesting and facebook has a good track record with making modern libraries and implementations.
- barnyfried 7y ago
  facebook, "better" hmmm
logicchains 7y ago
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.
7kmph 7y ago
Compared with the type checker in Haskell elm rust, dialyzer isn’t that good, we tried it two or three years ago in our project, I wouldn’t even call it useful.
- dnautics 7y ago
  It's more useful with a code editor that runs it all the time and subtly encourages you to write specs.
skrebbel 7y ago
Dialyzer is absolutely terrible though. I know of no modern, widely used programming tool that has worse error messages. And showing error messages is its only purpose. It'll tell you there's a problem in function x and actually the problem is 4 functions down the stack. It's nuts, it's shit.
- hopia 7y ago
  I agree, I've had nothing but trouble with it. Just the other day, I don't know if serious or not, I read the Phoenix framework's author say I solve 100% of my dialyzer issues by not using dialyzer on Slack.
  - PaulStatezny 7y ago
    Funny thing is, I agree that the error messages are terrible, but it catches legitimate bugs sometimes. I've seen at least a few dozen bugs caught in development over the last few years caught by Dialyzer.

If this was true, i suspect theirs would be better. Dialyzer doesn't seem very interesting and facebook has a good track record with making modern libraries and implementations.

barnyfried 7y ago
facebook, "better" hmmm

logicchains 7y ago

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.

7kmph 7y ago

Compared with the type checker in Haskell elm rust, dialyzer isn’t that good, we tried it two or three years ago in our project, I wouldn’t even call it useful.

dnautics 7y ago
It's more useful with a code editor that runs it all the time and subtly encourages you to write specs.

skrebbel 7y ago

Dialyzer is absolutely terrible though. I know of no modern, widely used programming tool that has worse error messages. And showing error messages is its only purpose. It'll tell you there's a problem in function x and actually the problem is 4 functions down the stack. It's nuts, it's shit.

hopia 7y ago
I agree, I've had nothing but trouble with it. Just the other day, I don't know if serious or not, I read the Phoenix framework's author say I solve 100% of my dialyzer issues by not using dialyzer on Slack.
- PaulStatezny 7y ago
  Funny thing is, I agree that the error messages are terrible, but it catches legitimate bugs sometimes. I've seen at least a few dozen bugs caught in development over the last few years caught by Dialyzer.