[weatherlight]

It's not that hard, also Elixir is basically gradually typed with dialyzer. It's not like working on a dynamic and weakly typed lang like vanilla JavaScript or Perl at all.

I do want to clear something up. Elixir is strongly typed, but its not statically typed.

More here: https://www.educative.io/answers/statically-v-dynamically-v-...

Even for langs that are statically/ and strongly typed on the BEAM (like Gleam, whose type system is similar to that of Standard ML or OCaml) still subscribe to the "Let is Crash" philosophy, especially when it comes to messages sent and received between processes. The only thing that is guaranteed is your system will fail at some point, how should the system protect its self form that?

https://www.educative.io/courses/concurrent-data-processing-...

In short, its not like working with Ruby or JavaScript or Python, etc..

[turdprincess]

The “let it crash” philosophy is great, but at the same time a proper static type system protects you from a whole class of crashes before they ever reach deployment.

If you change the shape of a model object and break its type, it’s great that BEAM will gracefully handle that mistake, but no matter how many times that service restarts, it will still be broken at runtime.

I think type systems have gotten so good in modern languages (Kotlin for example) that it’s a disservice to your org to not use a statically typed language.

I haven’t looked at Dialyzer lately, but is it as robust and easy to use as a first class type system? Having experienced partial typing with annotations with python I must say it’s not nearly as smooth as a proper statically typed language.

I do wish something like Gleam was the front runner language on BEAM - I bet it would get taken a lot more readily.

[weatherlight]

Dialyzer is good enough for my use-cases, especially in large web apps. In fact, Elixir's dynamic nature, when combined with Dialyzer and the BEAM's fault-tolerance features, offers a reasonable middle ground that has proven robust in large-scale systems.

Comparing it to Python's gradual typing isn't entirely fair for a couple of reasons:

1) Elixir is functional, meaning a value's type never changes. This makes it easier to reason about the code and allows tools like Dialyzer to be more effective.

2) The combination of value/pattern matching and the "let it crash" philosophy is unique to the BEAM ecosystem and has proven invaluable for building complex applications. this out side of Dialyzer gets you 80% the way there. (I don't even use Dialyzer in my applications because I don't think it buys you that much. I lean on testing, typically to cover that last 20%)

I'm intrigued, however by the new type system that's being explored for Elixir by Jose and this team. It promises the best of both worlds: dynamic typing with the assurances of a static one.

If we were to impose a Java/Kotlin-like type system onto Erlang/Elixir, there would be several concerns:

    It could encourage harmful coding practices that hinder code evolution.
    It might conflict with the "let it crash" philosophy, leading to more "nanny coding."
    The effort required to satisfy the type system could outweigh its benefits.
    It could reduce productivity and readability.
    If not integrated into the BEAM core, it might not offer optimization benefits and could create compatibility issues.
    It could divide the community and distract from other important work.

Elixir's existing features like testing, value matching, and the "let it crash" philosophy already provide a robust safety net that a static type system might not significantly improve upon.

[waynesonfire]

A common pattern that I use is to pass a behaviour module as a function argument to support dynamic behavior or dependency injection. Last I looked, I couldn't use dialyzer to describe the behaviour that a function accepts.