It's like saying they are both Turing Complete or that SML modules and Haskell typeclasses are functionally equivalent (even though their use in practice is quite different).
Aactors must always have a known address to be accessed and you share them by sharing addresses. You also wouldn't pass an actor to an actor and you'd pass an address instead. CSP channels are first-class. You can create anonymous channels and even pass channels through other channels. This is similar to languages with lambdas and first-class functions vs other languages where every function has a name and functions cannot be passed to other functions.
Actors are naturally async-only and (for example) make no attempt to solve the two generals problem while CSP implementations generally try to enforce synchronization. CSP also enforces message order while actors don't guarantee that messages will be received in the order they were sent.
These are all more theoretical than actual though. CSP channels may be anonymous to the programmer, but they all get process IDs just like Actors would. Actors may seem async, but they can (and no doubt do in practice) make stronger guarantees about message order and synchronicity when on the same CPU. Likewise, CSP would give the illusion of synchronicity and ordering across CPUs where none actually exists (just like TCP).
And what you’re saying is like saying that learning every distinct discipline is a unique experience. All knowledge was discovered by humans (even if by discovering it from nature), and all pedagogy addresses the same type(s) of brains. All disciplines contend with the same universal laws of physics. There is a lot less difference than people think between learning the flute and learning woodworking, even though the flautist may be much more discouraged from bringing their own hand-made gadgets to work.
But yes, many solutions are isomorphic because they are dealing with the same information on the same Turing machine. That doesn’t mean it’s stupid to bring it up, but it can mean that there’s a less upside to switching solutions than people think.
The Chesterton’s Fence here though is that you can implement the Actor Model without the BEAM’s process isolation, and the supervisor tree that goes with it. If you insist on doing so, which several languages have, then the finer distinctions between CSP and Actor pale in comparison to the BEAM.
Aactors must always have a known address to be accessed and you share them by sharing addresses. You also wouldn't pass an actor to an actor and you'd pass an address instead. CSP channels are first-class. You can create anonymous channels and even pass channels through other channels. This is similar to languages with lambdas and first-class functions vs other languages where every function has a name and functions cannot be passed to other functions.
Actors are naturally async-only and (for example) make no attempt to solve the two generals problem while CSP implementations generally try to enforce synchronization. CSP also enforces message order while actors don't guarantee that messages will be received in the order they were sent.
These are all more theoretical than actual though. CSP channels may be anonymous to the programmer, but they all get process IDs just like Actors would. Actors may seem async, but they can (and no doubt do in practice) make stronger guarantees about message order and synchronicity when on the same CPU. Likewise, CSP would give the illusion of synchronicity and ordering across CPUs where none actually exists (just like TCP).