> Actually, I think the next big unlock in user adoption is static typing.

From reading that post, it sounds like Jose does not believe static typing is needed. But a nice to have to address a very narrow set of use cases that primarily would help for documentation, not bug mitigation.

I think that Jose makes a solid case that static typing doesn’t bring as much to the table to Elixir as most people believe, but enough people point to the lack of it as a reason not to adopt the language that it’s worth addressing. Again, I think @spec is great and people should use it more – just treat the dialyzer warnings as errors.

Typespec is a nightmare to work with. The error messages are arbitrary and at times misleading. I use it because it is better than nothing, but it has much room for improvement.

I think I've encountered a couple of times where I've gotten obscure errors, and I agree that error messaging needs to be improved. On the other hand, every time it's pointed out an error, it was right. And IMHO union type-checking alone puts it above most popular static-typed languages out there.

The other problem with specs is that they can become out of sync with function signatures.

Dialyzer is almost always right but I've been using Elixir for around 4 years and I occasionally still find it difficult to decipher its verbose and deceiving messages.

I previously worked with TypeScript which felt like a major productivity boost but I've ran into a few instances where Dialyzer came up with the most cryptic error message that took me at least an hour to figure out. It really sucks when that happens and I wish there were more high quality learning materials that would dive into Dialyzer.

Yep, I've had some weird errors with Dialyzer, but in the mobile world I've had some similarly baffling errors from Kotlin and Swift, particularly around lambdas and generics. Let's not forget that the typing flexibility allowed in Elixir is really quite powerful compared to other languages.

I wish some LLM magic sauce could be applied to compiler and linter warnings in general that provide a context-appropriate plain language explanation, along with suggestions and automated fixes.

> In the meantime I don’t know what people have against using @spec.

It's not ergonomic enough (you end up writing function definitions twice).

And there's very little tooling to help automate the process: if you return the result of a function call, good luck figuring out the spec for that if that function is in a library somewhere