Elixir/Erlang/BEAM, as far as I know, semantically don't just come close, they arrive. I say "semantically" because there are some optimizations for things like large binaries so the system isn't literally copying a lot of them around unnecessarily, but semantically, BEAM processes are isolated from each other entirely.

Go doesn't come close; technically it's just another shared-state programming language. Culturally, it tends to use more sane concurrency features, and the channels are nice and all, but technically there is no isolation between goroutines.

With discipline, you can program Go with an actor mentality and it's fairly effective. I do it all the time, leaning on my years of experience in Erlang and some Haskell, which teaches you how to build systems that work that way. But you do need non-trivial discipline as the language provides rather less help with than I'd like.

Sharing state is what actor model tries to eliminate, it has a very strong locality concept. Singleton in OOP (which you have to implement atomic and thread safety often by yourself) can be easily implemented as an actor. Erlang has gen_server for this exact scenario. About isolation, you can actually impose class isolation in OO languages by declaring all variables as private. Public variable can never happen in actor model

> OO programming where classes are completely isolated

That sounds like COM, especially the Automation subset.