Hacker News Reader

Comment by josevalim | Hacker News Reader

Those are two distinct capabilities.

Static analysis in Elixir is quite more accessible because you rely way less frequently on dynamic dispatch than Python (or Ruby or JS). You typically know which module you are calling to, structs and pattern matching tell you about fields (which we verify at compile-time) and primitive type information. Things like deprecated and undefined functions are part of the compiler, while most other dynamic languages typically require type systems or linters (or do it exclusively at runtime).

I agree on type analysis though. It is better than nothing but that's not much to talk about. We are working on it. :)

View on HN

Ok fair, compared to other dynamically typed languages Elixir’s static analysis is better, by virtue of existing at all :-) Something is better than nothing, but getting “function has no local return” when you make a particular kind of typo three modules down the stack is a long way from eg Java or TypeScript just telling you about the typo, instantly, right where you made it. That’s the norm IMO and that’s what I was referring to.

I’m excited to hear that Elixir may be getting a bit closer to that, and I agree with your observation that because typical Elixir code uses dynamic dispatch very little, there’s a lot of room for improvement in ways that eg Ruby will never be able to offer.

I’m sorry about the “terribly, laughably” bit of my comment.

No worries!

For what is worth, I was not considering Dialyzer as part of my reply. You should be getting many warnings related to typos from the compiler!

Anyway I agree with the sentiment: we have a high ceiling but we are currently far away from it. If we had a Dialyzer that runs all the time, is fast (Erlang/OTP 26 already improved here), and has good error messages, it would already be great.

We are currently researching a proper type system into the language. Fully integrating and improving the Dialyzer experience would be our plan B.

Wow that would be great! I recall reading that an effort some years ago to do a type system on top of Erlang failed because typechecking inter process communication got too messy (or slow). Personally, I feel like a type system that leaves message passing completely out of scope would solve so many problems already. And then people can invent typechecked GenServers and the likes in userland.

I mean when 2 NodeJS processes communicate via JSON over HTTP then those aren’t typechecked either, even if their codebases are all TypeScript. Except, of course, when using the same TS rpc lib on both sides of an interface, with some code sharing between them so they use the same types.

I feel like even when all typechecking happens only on regular static synchronous function calls, and message passing is left out of scope, it’ll be so extremely useful. And like you said, the low amounts of dynamic dispatch makes it tractable. Still a huge amount of work I bet though :-)

Reply on news.ycombinator.com