Hacker News Reader

Comment by passer-by-123 | Hacker News Reader

A type system will allow you to catch a certain category of errors. There are still whole categories of logical errors and runtime errors, such as the ones that arises with communication with other systems and processes, that you can’t foresee and making sure that your system will go back to a working state in face of those errors is essential.

From this perpective, a type system is a nice to have and a recovery mechanism is a must have.

However, a type system is much more than preventing a certain class of errors. It is documentation, it is a design tool, it can improve performance, and others. Plus, if you can catch errors earlier, why not? At the end of the day, I would love a type system in Elixir, but I am certainly happier that the recovery system is there right now.

View on HN

Thanks for your reply. Your response is extremely spot on. I agree that a type system will _not_ catch all errors, only some.

My limited point was: it would be interesting to see statistically what % of time the ERTS (in real deployed production systems) is dealing with errors that could have been avoided at compile time (had their been a static typing system) and how many times are there real runtime errors (which can not be detected by a static type system). Of course with those kind of runtime errors the whole concept of supervision trees etc. is invaluable.

Surely someone's collected statistics on this and reported on it? Is there some kind of 'IT anthropology' field perhaps that does these kinds of things?

are you aware of dialyzer?

While Dialyzer can be handy, it is not a type system.

Elixir/Erlang do have typespecs, which helps on the documentation aspect, but a type system would give much more on the performance and guarantees departments.

Dialyzer works on success typing, which only tells you when it's certain there's a bug, but will stay silent if it's unsure. Even at the highest settings I couldn't get the same lovely iteration loop that you get in an ML-style language (like Haskell, Elm, Rust, etc) that I've come to expect, where you feel like you are having a conversation with the tool.

At the time I was attempting to use it, it was also super slow, and libraries were not keeping their typespecs up-to-date. Also a big one: no parametric polymorphism results in `any`s galore. :/

It basically starts with a notion that your program is correct, and then runs through all the facts it can collects about dependencies and your code, and then if it finds some contradiction, it warns. It does weird things though for optimization, such as replacing long lists of literals with any() after a certain point, or merging structs into bizarre-o franeknstructs like %{:__struct__ => A | B, :a => int(), :b => int(), :shared => int()} if A and B have that :shared field in common and your typespec is A.t() | B.t().

Reply on news.ycombinator.com