It's likely Armstrong conflated the two there because a significant part of the fault tolerance of Erlang comes from the loose coupling via message passing between components, which in no small part is tied to the dynamic typing. It's a Postel's law thing, being generous in what you accept and strict about you send.

Elixir's seamless pattern matching paradigm, IMO, largely negates the need for strict typing. If you write your function signatures to only accept data of the type / shape you need (which you are incentivized to do because it lets you unpack your data for easy processing), then you can write code just for the pretty path, where things are as expected, and do some generic coverage of the invalid state, where things aren't, rather than the norm in software development of "I covered all the individual failure states I could think of". This generic failure mode handling, too, greatly benefits from dynamic typing, since in my failure state, I by definition don't know exactly what the structure of my inputs are.

Yep, I have written and maintained several large scale applications In elixir and live the computation model.

However,elixir depreately needs proper types. IMHO the needs for types are in no means negated by pattern matching, and I also see hints at why you would say so.

> If you write your function signatures...

The point of types is worry less refactoring.

If you work at a place where you can define the arhicture for the entire lifecycle of the application without ever needing to Refactor, then sign me up! I want to work there.

no, but effort is a finite resource so it justifies why they didn't bother.

Well, the people behind elixir seems to have accepted that typing is necessary.

I see this story on an on: some hacker makes a language, they hate types because they want to express themselves. The languages gets traction. Now enterprise application and applications with several devs use it and typing gets essential - types will then gradually be added.

sure, a few years behind typescript/mypy isnt really so bad for a language without a microsoft or a google behind it, is all im saying.

> isnt really so bad for a language without a microsoft or a google behind it, is all im saying

What? Elm was literally the result of a single grad students side project - elm incorporates both a sound type system and FRP.

This has nothing to do with time. It was a decision not to support it.

sure part of the decision is that you can't really soundly type (in a developer sanity preserving way) across a cluster that runs multiple versions of software (which is a real use case that the authors absolutely needed to support as part of the core business). but they let dialyzer in to the core so it's not like the team was actively hostile to typing.

These are some weird sentences thrown into this thread.

What you are describing is a runtime concern that has nothing to do with types.

These issues are neither amplified nor alleviated by using types.

Okay? But "the features you need would have taken effort to implement, so we didn't implement them" is not a very good sales pitch when you're trying to convince me to use your tool to do my job.

ok. don't use it then. but be aware: your attitude is why things get stuck in (sometimes really awful) local minima in tech.

Any tool that justifies the choice not to implement an important and highly-requested feature with "effort is a finite resource" alone is not viable for serious development work. It's not prioritizing, it's a refusal to prioritize.

you probably shouldn't bulldoze into a situation with assertions like you've made with such a limited grasp of the history at play.