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•2h ago
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?
schultzer•2h ago
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•49m ago
"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.
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/
schultzer•3h ago
wk_end•2h ago
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?
schultzer•2h ago
dcsommer•49m ago
The type system is one of the weakest parts of the beam ecosystem.
troupo•42m ago
Munksgaard•8m ago
0: https://en.wikipedia.org/wiki/Strong_and_weak_typing
1: https://en.wikipedia.org/wiki/Type_system#Static_type_checki...
Munksgaard•3m ago
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/