The Strand programming book states that an early version of the Erlang runtime was implemented in Strand (see "13.1: History" http://www.call-with-current-continuation.org/files/strand-b...), which is an interesting tidbit that I haven't seen come up when the history of Erlang is discussed, like in the featured article.
It’s fascinating how long the BEAM has lasted. And even more fascinating how relevant its concurrency model still is in today’s async-heavy world. Built different.
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!
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?
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.
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.
"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.
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.
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.
Studying the BEAM is definitely on my ToDo list. It's task parallelism sounds exemplar, and I really want to understand the architectural ramifications of choosing fine-grained task parallelism vs. a data parallel-friendly approach.
The Strand programming book states that an early version of the Erlang runtime was implemented in Strand (see "13.1: History" http://www.call-with-current-continuation.org/files/strand-b...), which is an interesting tidbit that I haven't seen come up when the history of Erlang is discussed, like in the featured article.
It’s fascinating how long the BEAM has lasted. And even more fascinating how relevant its concurrency model still is in today’s async-heavy world. Built different.
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!
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?
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...
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.
"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.
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...
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.
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.
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
Studying the BEAM is definitely on my ToDo list. It's task parallelism sounds exemplar, and I really want to understand the architectural ramifications of choosing fine-grained task parallelism vs. a data parallel-friendly approach.
Love beam
I just wish elixir had static typing built in :)
Give Elixir a try anyway, you might be surprised:
https://arrowsmithlabs.com/blog/you-might-not-need-gradual-t...
I wish articles like this had more meat on why BEAM is good.
You have to say why it's good. E.g. https://news.ycombinator.com/item?id=28015852
If only there was a typed language that didn't hand wave serialization
I don't think we'll ever do better than 'IO is made out of bytes'.
Like Java?