[wk_end]

Does Erlang/Elixer have any edge over Ocaml or Haskell in that niche? They also have pattern matching, of course, and strong static types tend to work nicely for compilers too.

Of course, the big superpower they have is the BEAM and the robust multiprocessing support there, but that’s not especially helpful for compilers…or is it?

[Munksgaard]

As someone who has used both SML, Haskell, Rust and Elixir professionally: No, not really.

Access to the BEAM is nice, but unless you're targeting the BEAM in your compiler I don't see any benefit. Even if you're targeting the BEAM, you might decide to use another language, cf. Gleam: https://github.com/gleam-lang/gleam/

Edit: Actually, one thing I will mention is the superior support in Elixir/Erlang for pattern matching bitstrings[0]. Not usually helpful in compilers, but an evolution of pattern matching that other languages should take up, in my opinion.

0: https://hexdocs.pm/elixir/Kernel.SpecialForms.html#%3C%3C%3E...

[Rendello]

Erlang's bitstring/binary handling is one of those things that once you use, you'll wonder why it's not in every language (alongside, for me, Rust's enum/sum types and Python's badly-named but wonderfully useful while-else).

[tikhonj]

OCaml also has a binary string pattern matching feature which sounds pretty similar: https://practicalocaml.com/parsing-with-binary-string-patter...

[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...

[lolinder]

You can't really use the word "certainly" when speaking about "strongly typed" because the entire concept is fuzzy and subjective. From the article you linked:

> > However, there is no precise technical definition of what the terms mean and different authors disagree about the implied meaning of the terms and the relative rankings of the "strength" of the type systems of mainstream programming languages. For this reason, writers who wish to write unambiguously about type systems often eschew the terms "strong typing" and "weak typing" in favor of specific expressions such as "type safety".

I personally think the whole concept of "strongly typed", which is usually used as a prop to make dynamic languages count as part of the cool kids typed-languages club, should be ditched as a point of argument. The supposed "weakly typed" languages people are usually comparing to (like C) aren't actually framed as viable alternative for problems dynamic languages are suited for, so they're something of a straw man. I'd like to see advocates for dynamically typed languages ditch the obsession with having types like the cool kids and instead focus on showing why dynamism is valuable.

There are plenty of great cases to make for dynamism without having to argue on rhetorical ground that the static languages defined and dominate.

[Munksgaard]

I agree that the terminology is not ideal, but think there's a huge difference between JS' "weak types", i.e. abundant implicit conversions, and e.g. Elixirs "strong types", where `1 + "foo"` is a runtime error. I don't care if we call the latter something else though. Any good suggestions?

That said, I prefer having both strong and static typing, but that's another argument.

[zbentley]

I'd suggest "high-cast" and "low-cast". They draw attention to the thing that people usually mean when they talk about strong (not static) typing: whether operations in a language bias towards automatically coercing types so that a non-type-error result can be produced or not. High-cast languages tend towards requiring explicit type conversion; low-cast languages tend towards both implicit conversion and more complex behaviors when more than one type is supplied to a given operation. Also, the terms pun nicely with "high-cost" and "low-cost".

That said, it's still a spectrum and there's a lot of subjectiveness here. Everyone agrees that '1 + "foo"' is meaningless, but what about string multiplication? If a language documents that an integer multiplied by a string repeats the string, is that weakly typed/low-cast, or is it just documented multiplication operator behavior? If string multiplication is a whole separate operator, is that more strongly typed (and if so, are we all gonna be able to sleep at night since that means Perl 5 is more strongly typed than Python)?

That subjectiveness extends into the domain of hidden runtime costs, as well. Theoretically, any iterable of hashable items can be passed to a language's implementation of "HashSet::union(items)". But the implementation/performance of "union()" might differ based on the type of the iterable: should we be allowed to pass a lazy iterator which produces values after arbitrary custom computations? Many languages say "yes" here, but some consider collecting/each-ing the iterator something that must be explicit so the cost/exhaustion/side-effectfulness of the iteration is made clear. How about unioning a set with a vector, versus another set? Very different algorithmic behavior happens inside the union if another hash set is supplied instead of, say, a static array or linked list; while the complexity for nonlazy unions is always O(N), the average complexity/wallclock performance may be very different. Rust's stdlib, for example, discourages this kind of heterogenous union (not, I suspect, out of a desire for high-cast-explicitness, but because it wants to encourage use of its lazy O(1) union system instead). Are the answers to that question part of the high-cast/low-cast (or strong/weak type system) spectrum, or are they just specific choices made by each language's collections library? Ask 10 programmers, and I suspect you'll get a lot of different answers.

[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