3 ms·

> type analysis, static analysis These two are so terribly, laughably bad in Elixir that you listing them as advantages makes me doubt the integrity of your en

> type analysis, static analysis These two are so terribly, laughably bad in Elixir that you listing them as advantages makes me doubt the integrity of your entire post.

anonzzzies 3y ago
Worse than Python? It's a question; I don't know. I do know that the two most terrible (for me; I like types and a working IDE that helps me, not fight me) languages (js/py) are also the most popular. I don't know what that means, but as I did build large systems with Erlang in the past (in banking) which are still running production with massive load (and don't fall down in 2 weeks because the ENTIRE ecosystem had a minor version update, invalidating all the ABI's), I cannot imagine it's worse than Python or JS. I hope you can tell me.
- foldr 3y ago
  Python has at least a couple of functional type checking systems. Elixir only has Dialyxer, which has never actually worked for me any time I’ve attempted to use it. (It’s not just me. At work we have a medium-sized Phoenix codebase and about every fifth person who joins is determined to add Dialyxer to our CI pipeline - so far without success.)
  - bmitc 3y ago
    I use Dialyzer on all side projects and it always works. However, I enforce via Credo that everything gets a typespec, and I employ type-driven design. Dialyzer and Credo for Phoenix does require some workarounds, as that project isn't interested in providing typespecs or base compliance with Credo and is very heavy on macros.
    - foldr 3y ago
      I believe you. However, the current Dialyzer/Dialyxir experience bad enough that the creator of Elixir is working on an effort to specify an entirely different† gradual typing system for the language: https://news.ycombinator.com/item?id=36282419 https://news.ycombinator.com/item?id=36282419 https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... This strongly suggests that Dialyxir is not working as effectively for most users as e.g. Typescript or Mypy. † I can imagine people quibbling with 'entirely different', but the proposed type system does have a new(ish) theoretical basis that's still the subject of active research.
411111111111111 3y ago
My last weekend Project in Elixir is roughly 3 yrs ago now, but from what I recall the system was leagues better then pythons optional typing. It's just bad if you're used to languages that have been built around types from the start.
- foldr 3y ago
  I think you’re just saying that you prefer dynamically typed languages. The point here is that Python now has much better options than Elixir if you want to check types statically.
  - 411111111111111 3y ago
    I'm not sure how you could've gotten that idea from my comment. If I put it on a line, I'd say (no typing) < (python optional types) < (elixirs structs and pattern matching) < (typescripts types|interfaces) < (real static types from Java etc)
    - foldr 3y ago
      Hmm, ok, but structs and pattern matching aren’t static types. They certainly don’t offer anything like the kind of type safety you can obtain (with some effort) with mypy or other Python type systems. Mypy is quite similar to Typescript.
josevalim 3y ago
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. :)
- skrebbel 3y ago
  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.
  - josevalim 3y ago
    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.
    - skrebbel 3y ago
      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 :-)
bmitc 3y ago
By type analysis, I mean Dialyzer and built-in type errors, and by static analysis, I mean Credo and its ability to define custom checks and Elixir's ability to access and walk its own AST plus the compiler features. Yes, Dialyzer could be better, but it's pretty good if you write typespecs. But Credo is quite good and one of the best such tools I have ever used. And Elixir g enerally has excellent error messages. Why do you say it's laughably bad? Also, the point was primarily that all these tools are effectively built-in to the language without several different competing libraries. And I neglected to mention the official formatter.

> type analysis, static analysis These two are so terribly, laughably bad in Elixir that you listing them as advantages makes me doubt the integrity of your entire post.

anonzzzies 3y ago

Worse than Python? It's a question; I don't know. I do know that the two most terrible (for me; I like types and a working IDE that helps me, not fight me) languages (js/py) are also the most popular. I don't know what that means, but as I did build large systems with Erlang in the past (in banking) which are still running production with massive load (and don't fall down in 2 weeks because the ENTIRE ecosystem had a minor version update, invalidating all the ABI's), I cannot imagine it's worse than Python or JS. I hope you can tell me.

foldr 3y ago
Python has at least a couple of functional type checking systems. Elixir only has Dialyxer, which has never actually worked for me any time I’ve attempted to use it. (It’s not just me. At work we have a medium-sized Phoenix codebase and about every fifth person who joins is determined to add Dialyxer to our CI pipeline - so far without success.)
- bmitc 3y ago
  I use Dialyzer on all side projects and it always works. However, I enforce via Credo that everything gets a typespec, and I employ type-driven design. Dialyzer and Credo for Phoenix does require some workarounds, as that project isn't interested in providing typespecs or base compliance with Credo and is very heavy on macros.
  - foldr 3y ago
    I believe you. However, the current Dialyzer/Dialyxir experience bad enough that the creator of Elixir is working on an effort to specify an entirely different† gradual typing system for the language: https://news.ycombinator.com/item?id=36282419 https://news.ycombinator.com/item?id=36282419 https://elixir-lang.org/blog/2022/10/05/my-future-with-elixir-set-theoretic-types/ https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... This strongly suggests that Dialyxir is not working as effectively for most users as e.g. Typescript or Mypy. † I can imagine people quibbling with 'entirely different', but the proposed type system does have a new(ish) theoretical basis that's still the subject of active research.

411111111111111 3y ago

My last weekend Project in Elixir is roughly 3 yrs ago now, but from what I recall the system was leagues better then pythons optional typing. It's just bad if you're used to languages that have been built around types from the start.

foldr 3y ago
I think you’re just saying that you prefer dynamically typed languages. The point here is that Python now has much better options than Elixir if you want to check types statically.
- 411111111111111 3y ago
  I'm not sure how you could've gotten that idea from my comment. If I put it on a line, I'd say (no typing) < (python optional types) < (elixirs structs and pattern matching) < (typescripts types|interfaces) < (real static types from Java etc)
  - foldr 3y ago
    Hmm, ok, but structs and pattern matching aren’t static types. They certainly don’t offer anything like the kind of type safety you can obtain (with some effort) with mypy or other Python type systems. Mypy is quite similar to Typescript.

josevalim 3y ago

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. :)

skrebbel 3y ago
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.
- josevalim 3y ago
  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.
  - skrebbel 3y ago
    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 :-)

bmitc 3y ago

By type analysis, I mean Dialyzer and built-in type errors, and by static analysis, I mean Credo and its ability to define custom checks and Elixir's ability to access and walk its own AST plus the compiler features. Yes, Dialyzer could be better, but it's pretty good if you write typespecs. But Credo is quite good and one of the best such tools I have ever used. And Elixir g enerally has excellent error messages. Why do you say it's laughably bad? Also, the point was primarily that all these tools are effectively built-in to the language without several different competing libraries. And I neglected to mention the official formatter.