[schultzer]

Elixir compiler is written in Erlang, Erlang can produce very efficient code, the new json library can beat c libraries at decoding / encoding. And you get this with a strongly typed dynamic language, which is a distributed language. It’s really hard to beat the BEAM, if only we had better number crunching, but in so cases you can always write a nif.

[dcsommer]

"Strongly typed" is stretching it. Type checking is bolted on and not part of `erlc`. Typing is quite unergonomic in Erlang/Elixir (similar to Typescript bolted onto JS).

The type system is one of the weakest parts of the beam ecosystem.

[Munksgaard]

Erlang/Elixir are certainly strongly typed[0] but they are not statically typed[1].

0: https://en.wikipedia.org/wiki/Strong_and_weak_typing

1: https://en.wikipedia.org/wiki/Type_system#Static_type_checki...

[troupo]

Elixir team is slowly bringing in type checking into the language: https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi... and https://hexdocs.pm/elixir/gradual-set-theoretic-types.html

[cess11]

Dialyzer might be considered "bolted on", but the BEAM itself is strongly and dynamically typed. In Elixir the compiler is getting static typing as well.

https://learnyousomeerlang.com/types-or-lack-thereof

These languages have other properties that can play the role that types are sometimes relied upon to do. It's uncommon that I think in types at all when building things in Elixir, thinking about shapes usually gets me all the way.

In my experience string processing libraries are the weakest part, due to some of them having abysmal performance for whatever reason. Last I had this problem I wanted to do ETL on mbox files but gave up and did it with someone's PHP one-class weekend project instead.

[cess11]

You probably don't, Numerical Elixir/Nx has been out for years and did the NIF:ing for you.

It's one part of why it's quite convenient to juggle ML and LLM tasks on the BEAM, and easy enough that I can manage it.

https://github.com/elixir-nx