[hansonkd]

I think a lot of issues BEAM was trying to solve were solved by processors getting bigger and more cores.

BEAM's benefit 10-20 years ago where that inter-node communication was essentially the same as communicating in the same process. Meaning i could talk to an actor on a different machine the same way as if it was in the same process.

These days people just spin up more cores on one machine. Getting good performance out of multi-node erlang is a challenge and only really works if you can host all the servers on one rack to simulate a multi-core machine. The built in distributed part of erlang doesn't work so well in modern VPS / AWS setup, although some try.

[binary132]

“Just spin up more cores on one machine” has a pretty low scale ceiling, don’t you think? What, 96 cores? Maybe a few more on ARM? What do you do when you need thousands or tens of thousands of cores?

Well, what I do is think of functions as services, and there are different ways to get that, but BEAM / OTP are surely among them.

[gr4vityWall]

> What do you do when you need thousands or tens of thousands of cores?

I think most software won't need to scale that far. Did you run into any systems like that built on top of BEAM?

[binary132]

I’m just saying, erlang was built for telephony at scale, not for building some REST website. “You probably won’t need more than one big host for any given request” isn’t really a winning argument for scaled systems

[gr4vityWall]

Correct me if I'm wrong, but I believe "scale" in the original context meant developing a system with strong fault tolerance properties, so that if a node went down to ie a hardware failure, the system as a whole would keep working normally.

So, did you run into any systems that needed to scale to tens of thousands of cores for a reason inherent to the problem they were solving, and was built on top of BEAM?