[schultzer]

One thing that is great about Erlang’s pattern matching is that it makes it extremely approachable for writing, lexer, parser and compilers in it: https://github.com/elixir-dbvisor/sql and with Elixir macros and sigils then you can embed other languages like sql and zig to name a few!

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

[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