> IMHO the actor model is great until you need to share something across processes, then you have a distributed computing problem inside your program. I'm sorr

> IMHO the actor model is great until you need to share something across processes, then you have a distributed computing problem inside your program. I'm sorry, but your multicore computer (and most single core computers, too) are a distributed system, regardless of if you acknowledge it. Shared memory concurrency use implicit communicatiom between threads, but it's still communicating processes, you just don't have the same level of control and isolation. That said, of course there are situations where you can have better results with shared memory and there are situations where message passing is better. You can do shared memory in BEAM with ets, and if that doesn't meet your needs, with NIFs ... you likely lose out on some isolation, etc, and it won't always be a good fit. > Plus the JVM software ecosystem and runtime observability / battle-testedness is far better than BEAM. Maybe battle tested (although, I've certainly battle tested BEAM more than I've tested JVM; but I'll grant that many more people have done battle with the JVM)... but BEAM has quite extensive observability. You can see all sorts of stuff about every process, you can add tracing at run time. You can change the code at run time if you need to add more stuff; and runtime code changing is just in the normal setup, it's not exotic (although many people eschew it)