[davidclark]

Well written typespecs + dialyzer catches most things you’d want to catch with a type system: https://hexdocs.pm/elixir/typespecs.html

There is also pattern matching and guard clauses so you can write something like:

def add(a, b) when is_integer(a) and is_integer(b), do: a + b

def add(_, _), do: :error

It’s up to personal preference and the exact context if you want a fall through case like this. Could also have it raise an error if that is preferred. Not including the fallback case will cause an error if the conditions aren’t met for values passed to the function.

[conradfr]

Writing typespecs (+ guards) feels really outdated and a drag, especially in a language that wants you to write a lot of functions.

It reminds of the not-missed phpspec, in a worst way because at least with PHP the IDE was mostly writing it itself and you didn't need to add the function name to them (easily missed when copy/pasting).

[bevr1337]

I wouldn't lump guards and typespecs together. Guards are a runtime feature of erlang/elixir's excellent pattern matching.

Typespec is an opt-in type hint for develop and build time.

[conradfr]

True but by using guards + pattern matching structs you can approximate type hinting, but it feels cumbersome and more of a workaround than a real solution.

[bevr1337]

I'm of the opinion that Erlang/Elixir are terrible for repeat tasks like a standard CRUD server over a SQL database. Because yes, it IS cumbersome! Behaviors and type hints only get so far, and it is exhaustingly slow to sit with epgsql in the REPL to figure out what a query actually returns.

I find them much better suited for specific tasks where there is little overlap or repetition.