Jose has been working with some PhDs to attempt to implement static typing

https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi...

In the meantime I don’t know what people have against using @spec. It’s a far more powerful type specification than the majority of static-typed languages out there

> 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

The type checker from WhatsApp is open sourced and actively used. See https://github.com/WhatsApp/eqwalizer

You've been able to write PureScript that compiles to Erlang and has perfect interop for years, via `purerl`[0]. Using it with Elixir is as simple as adding `purerlex` as a compiler and having your PureScript code automatically compile when `mix` compiles things, and off you go.

In terms of the typing itself, it's exactly what you get in all of PureScript, strict static typing with no `any` or the like. Using `Pinto`, the de facto OTP layer in PureScript your processes are typed, i.e. their `info` messages & state are typed, which means that they are all much more like strongly typed state machines than anything else.

You can see an example of a basic `gen_server` here:

https://pastebin.com/UTEfz7Wg

The differences aren't very big in terms of what you'd expect to be doing. One small thing to note is that the `GenServer.call` expects a closure to be passed instead of having the split between `gen_server:call` & `handle_call`, removing the need for synchronizing two places for your messages being sent and handled.

0 - https://github.com/purerl/purerl

Edit:

As an upside you also have PureScript for your frontend, so you can just write everything in the same language regardless of how much frontend work you expect to be doing. PureScript has great bindings and a great story around React (it actually fits better since it's a purely functional language, so things like "You can only do effects in `useEffect` actually are enforced and make sense) and also has its own frontend framework in Halogen which is very nice.