[dpatterbee]

In elixir, processes (these are Erlang "processes", not OS processes) are designed to fail when they encounter errors, and the supervising process will restart it according to various rules you can configure. This isn't dissimilar to how kubernetes restarts jobs when they fail, but at a more fine-grained level.

It's actually intended that your function doesn't try too hard to validate it's input types, and just that it will malfunction and crash when it gets something it doesn't know how to handle, because the supervision tree will rescue it and your program can continue, albeit without whatever input caused the malfunction.

This obviously isn't ideal for many types of software, but for complex backend servers and other long-running operations it works really well.

Of course this is not a guarantee to eliminate bugs, but it's a factor that reduces them more than you'd think when coming from a different programming paradigm.

[awesome_dude]

I mean - you're arguing there about a small blast radius, and I genuinely appreciate that not taking down the whole system when a bug occurs is incredibly valueable.

But, the discussion is about dynamic typing, and the fact that the function is in a state where it cannot compute because of bad input.

This might as well be a Null Pointer Exception - the function has encountered bad input, and crashes.

The argument is, that a MUCH stronger position is for all callers to be forced to provide input that cannot get the function into such a state - and a major subset of the set of all inputs possible can be eliminated with static or strict typing (I know the nomenclature gets a bit hazy here, but I hope that my intended meaning is clear)

If the callers know in advance that they cannot provide input shaped in ways that the function will not handle, then they will not call the function in those ways.

And that forces the call chain to be sure about the data transferred from top to bottom.