Comment by onlyrealcuzzo

I'm working on a similar language.

The facts about Gleam:

1. It runs on the BEAM - exceptionally slow compared to Go, but infinitely scalable by default in a way that Go is not - in practice, very rarely matters.

2. They will argue the slowness doesn't matter -> if ~97% of time is spent waiting on I/O -> you can be 10x slower and that means you're only ~30% for typical applications -> it's easier to scale more machines on the BEAM than it is to scale a single machine -> this is true, but largely irrelevant in Go's core market -> it's almost as if Go was built by smart people.

3. The reality is that predictability is much harder to guarantee once you start moving components to different machines. Correct, predictable distributed computing makes correct, predictable concurrent programming look easy.

4. The BEAM does not allow shared memory, Go does (unsafely). There are many cases where the performance impact of this is night and day (why Go ultimately allowed unsafety).

I assume Gleam claims to make this just work. But as someone working in this space, this seems like trying to abstract away the difference between taking a boat to Europe or a plane.

Gleam may be nice if you're building something for the BEAM (massively scalable single app that just makes sense with the actor model, typically chat / telecom).

Though I question why you would use it over Elixir.

Go's syntax kind of blows, but it is so INCREDIBLY good at what it does, that you are not going to beat Go by just having better syntax and being "infinitely scalable" by default.

In practice, Go is easily scalable enough for almost anyone. If it isn't congrats, you're a $10B+ company. You can afford to rearchitect and optimize your hot paths.