3 ms·

I really don’t get this, personally. I’ve worked in Java, Ruby, Typescript, Elixir, JS, and a bit of Elm and I literally never feel like I’m missing anything by

by ch4s3 4y ago

I really don’t get this, personally. I’ve worked in Java, Ruby, Typescript, Elixir, JS, and a bit of Elm and I literally never feel like I’m missing anything by not having static types in Elixir. This is doubly true with web based projects. What are people looking for that they might get from static types?

Jcampuzano2 4y ago
I used to think this, but nowadays I avoid any language that doesn't have static typing. The difference in tooling support/IDE completions I get on practically any language that has types vs those that don't is just too drastic for me. It's also so much less mental load to have to always remember the types in my head. Another issue I've seen in dynamic languages is when people do try to document the types via comments or otherwise, but then this drifts from reality due to not being updated. I actually tried elixir and this is one of the main things that turned me off it.
- ch4s3 4y ago
  Completions in Elixir in VSCode are as good as anything if seen in intellij for Java, through that may be a low bar. As for the burden of the mental model, I can’t really speak to that. In Elixir I usually try to think in data shapes or structures which can be matched on by function heads. I only think of types at the edges of the system.
  - lukasz_samson 4y ago
    ElixirLS developer here. Nice to hear that people like the autocompletion but comming from .net/java I think it still can do much better. It’s not very context aware and poorly handles code with parse errors
    - ch4s3 4y ago
      It always works well enough for my purposes.
- throwawaymaths 4y ago
  It's way less of an issue due to vscode/elixir-ls auto running dialyzer in the background
- realusername 4y ago
  Elixir does have a very good autocomplete despite the dynamic typing, it's probably the best autocomplete I've ever seen for a non typed language. The reason for that is simple, the language works with modules and data pipes, not objects which means there's way less magic to parse
panzi 4y ago
For me: - Ease of refactoring once the project got to a certain size. - Preventing a lot of my stupid bugs (typos, passing the wrong type etc.). - Quicker and easier understanding of argument and return types. The types are a form of documentation! - Auto-completion and inline docs for library functions. - Fewer tests needed, since everything the type system does has to otherwise be tested by a manually written test. Just things anyone would tell you that appreciates static typing.
- ch4s3 4y ago
  I’ve worked on some pretty large codebases and while there’s usually no IDE button for it, there are good and well known patterns for refactoring dynamic code. As for bugs, the research on this has always been mixed at best, I guess YMMV. I’d personally argue that the structural typing in Elixir is more useful and practical than the types in most popular static languages like Java or TS. Mostly I think it’s a wash where you get a little but give up some useful things too.
ketzo 4y ago
In a large JavaScript codebase that's partway to being a TypeScript codebase, I find myself constantly having to insert `console.log` statements to find out what attributes some object actually has. Plus, our number one source of crashes and errors is unhandled null/undefined because someone didn't realize a parameter might be nullish. Static typing would basically eliminate both of those issues.
- ch4s3 4y ago
  I hear this about big JS codebases but the 7 year old Elixir app I work on is many 10s of thousands of lines of code and we just don’t have that problem.
  - throwawaymaths 4y ago
    It's not nothing but it's rare. After about two years I finally had a type error. It wasn't horrible, though, just caused extra log lines.
    - ch4s3 4y ago
      It’s not that we never have type errors, it’s just that they’re the least frequent kind of error I see monitoring sentry. We try to do a zero exception policy, so we’re really on top of what kind of errors are happening.
taude 4y ago
Size of projects and lifetime of project. Team members swapping in and out, moving project/repo ownership to another team, ability to make simple changes to a code base without having full understanding, etc.
- ch4s3 4y ago
  I'm working on a 7 year old application now with 60+ past contributors, 3-4 teams working in the code base, 3,500 elixir files, and some semi-complex dependencies and I can honestly say that most of it is pretty easy to work on. We have one section that is full of some really thorny code, but that's because it relies heavily on code generation and that's rough in most languages. Onboarding usually only takes about a week, less sometimes.

by ch4s3 4y ago

Jcampuzano2 4y ago

I used to think this, but nowadays I avoid any language that doesn't have static typing. The difference in tooling support/IDE completions I get on practically any language that has types vs those that don't is just too drastic for me. It's also so much less mental load to have to always remember the types in my head. Another issue I've seen in dynamic languages is when people do try to document the types via comments or otherwise, but then this drifts from reality due to not being updated. I actually tried elixir and this is one of the main things that turned me off it.

ch4s3 4y ago
Completions in Elixir in VSCode are as good as anything if seen in intellij for Java, through that may be a low bar. As for the burden of the mental model, I can’t really speak to that. In Elixir I usually try to think in data shapes or structures which can be matched on by function heads. I only think of types at the edges of the system.
- lukasz_samson 4y ago
  ElixirLS developer here. Nice to hear that people like the autocompletion but comming from .net/java I think it still can do much better. It’s not very context aware and poorly handles code with parse errors
  - ch4s3 4y ago
    It always works well enough for my purposes.
throwawaymaths 4y ago
It's way less of an issue due to vscode/elixir-ls auto running dialyzer in the background
realusername 4y ago
Elixir does have a very good autocomplete despite the dynamic typing, it's probably the best autocomplete I've ever seen for a non typed language. The reason for that is simple, the language works with modules and data pipes, not objects which means there's way less magic to parse

panzi 4y ago

For me: - Ease of refactoring once the project got to a certain size. - Preventing a lot of my stupid bugs (typos, passing the wrong type etc.). - Quicker and easier understanding of argument and return types. The types are a form of documentation! - Auto-completion and inline docs for library functions. - Fewer tests needed, since everything the type system does has to otherwise be tested by a manually written test. Just things anyone would tell you that appreciates static typing.

ch4s3 4y ago
I’ve worked on some pretty large codebases and while there’s usually no IDE button for it, there are good and well known patterns for refactoring dynamic code. As for bugs, the research on this has always been mixed at best, I guess YMMV. I’d personally argue that the structural typing in Elixir is more useful and practical than the types in most popular static languages like Java or TS. Mostly I think it’s a wash where you get a little but give up some useful things too.

ketzo 4y ago

In a large JavaScript codebase that's partway to being a TypeScript codebase, I find myself constantly having to insert `console.log` statements to find out what attributes some object actually has. Plus, our number one source of crashes and errors is unhandled null/undefined because someone didn't realize a parameter might be nullish. Static typing would basically eliminate both of those issues.

ch4s3 4y ago
I hear this about big JS codebases but the 7 year old Elixir app I work on is many 10s of thousands of lines of code and we just don’t have that problem.
- throwawaymaths 4y ago
  It's not nothing but it's rare. After about two years I finally had a type error. It wasn't horrible, though, just caused extra log lines.
  - ch4s3 4y ago
    It’s not that we never have type errors, it’s just that they’re the least frequent kind of error I see monitoring sentry. We try to do a zero exception policy, so we’re really on top of what kind of errors are happening.

taude 4y ago

Size of projects and lifetime of project. Team members swapping in and out, moving project/repo ownership to another team, ability to make simple changes to a code base without having full understanding, etc.

ch4s3 4y ago
I'm working on a 7 year old application now with 60+ past contributors, 3-4 teams working in the code base, 3,500 elixir files, and some semi-complex dependencies and I can honestly say that most of it is pretty easy to work on. We have one section that is full of some really thorny code, but that's because it relies heavily on code generation and that's rough in most languages. Onboarding usually only takes about a week, less sometimes.