Yup, that's my understanding too -- what Erlang does extremely well is abstract away and isolate the concurrency mechanisms, allowing you to think of the details of (these concurrent) processes, linearly.
I remember when I was learning Elixir—I asked my co-worker / Elixir mentor how Elixir solves concurrent programming, data access, etc. His cheeky but accurate response was "How do you solve a problem that you don't have?"
His point was that the paradigm is so different at the VM level, that many things become irrelevant to the conversation. That said, there still are concurrent programming challenges on the BEAM, but it's very minimal compared to languages where it's not baked in.
Ruby Ractor is a good example of how a VM-backed concurrency mechanism will likely change how programs in that language can be built.
