Comment by SamInTheShell
19 hours ago
I looked at BEAM about a year or so ago, similar conversation here. I don't think BEAM is the same when you start looking at what part of code is executing in which thread. There's tradeoffs depending on what you're solving for, like Go makes it really simple to distribute your work across threads concurrently, but when you start looking at integrating with stuff, you run into having to do tricks to do things with unshare (ref: docker/podman/containers...) and you haven't been able to integrate into libnss since they started using some "unused linux signal" for concurrency controls (PAM used that signal).
Their concurrency models are very similar. By default there is a thread per core and the scheduler can move a process to another thread at any time. All I/O is async. Like Go, when code calls into foreign native code (NIF / cgo) the scheduler puts it on its own OS thread.
One advantage BEAM had for a long time is preemption is built into the VM and based on reductions. Go didn't have true preemption until 1.14 (before that it could only preempt at function boundaries) and its a very complicated implementation based on async signals sent from a runtime thread.
Since you’re talking about threads in the context of the BEAM, you might want to give it a deeper look. There are no threads there, at least not OS threads on the developer’s disposal.
I don't have a use case where anything in my toolbox isn't already sufficient enough to solve, it wouldn't be worth while. Maybe if I cared to work at some big place or specifically Ericsson, but there's better things to be doing with my time. There's plenty of problems that can be solved with tools like uv/Python/PyWebView.
How the OTP handles Erlang/Elixir parallelism is kind of interesting. =3
https://blog.stenmans.org/theBeamBook/#_concurrency_parallel...