Cluster management is a hard problem. Erlang's cluster support really only hits one use case, which is that you've got a relatively small cluster... at least, by Google standards!... of several machines physically co-located, or at least, very close on the network together. That's a great use case to cover, but it is important to understand that's "all" it is. You can't build a 1000-machine, multiple-data center located around the world deployment on the default Erlang stack as if all those machines are on one cluster. What Erlang gives you is still a step up from the normal default; you can build that as a cluster in each DC and it's not that hard to start up "proxy processes" that allow you to talk to other machines in the data cluster via Erlang messages sent to processes... but now you're talking about doing work, not just using built-in support.

"cross-machine channels" are, in my considered opinion, impossible. The channel semantics include a synchronous rendevous that is impossible to guarantee over the network. (That is, when you advance past a channels send statement to a non-buffered channel, you are guaranteed that some other goroutine has received the value.) You can set up other objects that let you communicate remotely, but they can't be "channels"... they can only be other things.

(Note that you have to understand "Go channel" not as a vague "something that lets you send messages", but the specific and exact semantics it implements, which is important because without those very specific semantics, "select" doesn't work! And if you can't put it in a "select", it isn't a Go channel. Go channels have a very, very rich semantics full of strong guarantees, which can't be relayed across a network.)

Some of the rest of your last paragraph is fairly deeply addressed in this post of mine: http://www.jerf.org/iri/post/2930