3 ms·

I agree, but the main feature isn’t the language, but the BEAM VM. As far as I know there‘s no other language which focussed from the get-go on parallel, distr

I agree, but the main feature isn’t the language, but the BEAM VM. As far as I know there‘s no other language which focussed from the get-go on parallel, distributed deployment, has processes as first class primitives, supports hot code swapping etc.

igouy 1y ago
Well afaik is an argument based on lack of evidence. And why does from the get-go on parallel matter? Wouldn't it be OK if the initial focus was something else and then there was a change of focus? And processes as first class depends what you mean: https://live.exept.de/doc/online/english/overview/basicClasses/process.html#PROCESS https://live.exept.de/doc/online/english/overview/basicClass... And hot code swapping: Smalltalk.
- macintux 1y ago
  > Wouldn't it be OK if the initial focus was something else and then there was a change of focus? Retrofitting features into existing languages is rarely satisfying in my experience. Sure, Python now has functional constructs, but variables are still mutable, so bizarre things can happen inside a map call. In Erlang, immutability is baked into everything. Message passing can be added as a library, but you don’t get the same impact as everything being a message. Does your random 3rd party library also use messages? Probably not. Erlang is a very opinionated language and runtime with a small set of core concepts, and it is very predictable as a consequence. Java or C++ have just about any feature you can think of, which is beneficial in some ways, but they’re also much more complex.
  - igouy 1y ago
    rarely satisfying seems vague. Maybe we need requirements that can be checked by different individuals and give repeatable results. > immutability is baked into everything process dictionary
fogzen 1y ago
I haven’t worked much with BEAM/Erlang but having worked with real distributed applications I’m quite skeptical there’s much value in helping me send messages over the net between processes. That’s the trivial part of distributed systems. The hard parts of distributed computing like data consistency, consensus, or network partitions are left to the programmer. To say nothing about hardware. Something simple like a message queue has many ways it can be implemented in a distributed system. In Erlang every actor has its own queue. Great. I highly doubt I could actually use them in a real distributed system but I’d love to see that I’m wrong. Here's a trivial example from one of my recent jobs: We need to queue Slack messages from different producers into some kind of per-tenant outbox queue that ensures one consumer per tenant, and which consumes at a maximum rate (to stay below Slack rate limits). This queue also needs to be bounded and communicate back pressure to producers. What unique value does Erlang provide here? Usually this kind of thing is built using Go and AWS Lambdas and SQS or Kafka. Where does Erlang/BEAM help here?

igouy 1y ago

Well afaik is an argument based on lack of evidence. And why does from the get-go on parallel matter? Wouldn't it be OK if the initial focus was something else and then there was a change of focus? And processes as first class depends what you mean: https://live.exept.de/doc/online/english/overview/basicClasses/process.html#PROCESS https://live.exept.de/doc/online/english/overview/basicClass... And hot code swapping: Smalltalk.

macintux 1y ago
> Wouldn't it be OK if the initial focus was something else and then there was a change of focus? Retrofitting features into existing languages is rarely satisfying in my experience. Sure, Python now has functional constructs, but variables are still mutable, so bizarre things can happen inside a map call. In Erlang, immutability is baked into everything. Message passing can be added as a library, but you don’t get the same impact as everything being a message. Does your random 3rd party library also use messages? Probably not. Erlang is a very opinionated language and runtime with a small set of core concepts, and it is very predictable as a consequence. Java or C++ have just about any feature you can think of, which is beneficial in some ways, but they’re also much more complex.
- igouy 1y ago
  rarely satisfying seems vague. Maybe we need requirements that can be checked by different individuals and give repeatable results. > immutability is baked into everything process dictionary

fogzen 1y ago

I haven’t worked much with BEAM/Erlang but having worked with real distributed applications I’m quite skeptical there’s much value in helping me send messages over the net between processes. That’s the trivial part of distributed systems. The hard parts of distributed computing like data consistency, consensus, or network partitions are left to the programmer. To say nothing about hardware. Something simple like a message queue has many ways it can be implemented in a distributed system. In Erlang every actor has its own queue. Great. I highly doubt I could actually use them in a real distributed system but I’d love to see that I’m wrong. Here's a trivial example from one of my recent jobs: We need to queue Slack messages from different producers into some kind of per-tenant outbox queue that ensures one consumer per tenant, and which consumes at a maximum rate (to stay below Slack rate limits). This queue also needs to be bounded and communicate back pressure to producers. What unique value does Erlang provide here? Usually this kind of thing is built using Go and AWS Lambdas and SQS or Kafka. Where does Erlang/BEAM help here?