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.

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.

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.

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.

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

It always works well enough for my purposes.

It's way less of an issue due to vscode/elixir-ls auto running dialyzer in the background

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

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.

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.

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.

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.

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.

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.