(What makes Go different from C++ in the 1990s is more community practice around what concurrency patterns are most commonly used, rather than technical differences in the language. Technically Go is just a mutable threaded language; for this purpose details about how the threading is accomplished are not that important.)
In general the big difference with actors is that they are isolated from each other in some manner that means they can't just reach in to some other actor's memory space and manipulate the memory concurrently.
Languages are starting to blur the lines here. Rust's lifetime annotation is not on its own sufficient to call Rust an "actor-based language" but the fact that they also prevent threads/async processes from just reaching in and manipulating other threads/async process's value unexpectedly means you've certainly taken a big step in that direction. And while Go provides no language-level technical support for actors, I still have a lot of things that are de facto actors in Go that uses scoping and export rules to confine the ability of other goroutines to interfere with a particular "actor"'s values, combined with an API that enforces message-based communication even though it works through what look like normal methods. This is not enforced at all technically by the language but it works better with community code than it does in older thread-based languages because the Go community is more recent and you can generally rely on libraries using somewhat more modern concurrency primitives, like providing services based on actors or actor-like objects.
There are some things in programming where if you mostly follow some practice, you get most of the benefit. There are other things in programming where the benefit only kicks in if you do it almost entirely correctly; an example of the latter is Haskell's rigid insistence on functional programming and immutability, I'm not convinced that it's worth doing 90% of that but when you fully commit and build the language around it, there is an interesting spike in capability at the end.
After programming in this space for well over a decade now, I kinda feel like actors are in the former case. I'm not sure you truly need a full language-level dedication to them to get most of their benefits. There is a last level of confidence and surety you can get in a language like Erlang, but I still think in practice that's just a last incremental benefit rather than a sudden burst in utility as you get to 100% purity. I think it's fine to program an actor here and an actor there in other languages and you get the benefits right there on the spot. Even what benefit there is, things like Rust gain in a different way. Still, I've been watching Pony with some interest.