I've kind of gotten a

Scala : Gleam :: JavaScript : Lua

vibe from it.

They probably just mean "BEAM language that isn't Erlang."

All BEAM languages always bring something new to the table aside from just syntax (for Gleam it's static type, for Elixir it's macros and, well, mix!) but none of them try and abstract away the core tenants of the BEAM being functional working with modules and processes. So ya, in that sense you could say it's like Elixir.

>and cannot ever know

It might be resistant to human uptake in that case, too? Brett Victor I suppose has some interesting human-first or human-only physical computers.

You better start writing your own compilers then

You should learn Gleam then.

See you in 9 months then to check back.

> if I didn't believe firmly that we won't be coding by hand within the next 9 months.

LLM-assisted coding is awesome, but it feels like a self-driving style problem.

It's going to take 20 years to get there.

Doe LLMs write valid Gleam programs? Trying with ChatGPT three years ago, it did not. Workarounds, like "here is the syntax as a system prompt", put into the prompt I would not consider understanding, as Gleam idioms and patterns will certainly not all fit.

Or thanks to algebraic data types and pattern matching? Even in a modest recursive descent parser, these can be really nice to use.

The BEAM is an amazing piece of technology. It’s built to scale massive concurrent systems and has great developer ergonomics. I’ve used it with Elixir and it’s really a breath of fresh air as far as running a webserver goes. Much more flexible and simpler to manage than a python or nodejs runtime, and also capable of scaling up with far fewer resources than you would think. Highly recommend giving it a go!

The BEAM is very lightweight and necessary within Erlang to enforce one of its greatest tradeoffs:

- No universal garbage collector, every process (aka green thread) has its own heap that is reclaimed when it dies.

- No process can takeover the CPU. If you run a hugely intensive task in one process, everything else, millions of other processes potentially, will continue responding normally and consistently. The hugely intensive task will just take longer.

There’s more that applies to some advanced use cases, but these are the 2 core elements that are awesome.

I have never seriously used a BEAM language (Elixir/Erlang/Gleam), but for me, it’s the opposite: the most attractive part of Gleam is that it runs on BEAM :)

My reservations at this point are mostly around maturity of the language, the stdlib, and the library ecosystem; although I haven’t been following progress too closely.

You need the BEAM because operating systems we have available do not have the properties of the BEAM.

OS processes are far to heavy and slow to start, and the scheduler doesn’t work the way erlang needs it to. The BEAM solves those issues amongst others.

Also you need the BEAM for hot swapping code at runtime without taking the system offline.