Example from personal experience: I'm working on an audio app right now, and I have high bandwidth, low latency data. I'm CPU bound, allocations and the GC are my enemy. It's just not feasible to constantly copy those buffers around. :(
Don't take this the wrong way, I'm not complaining about Go. Just know that sometimes, there are real reasons to share memory. And when you do: Rust has got your back, but in Go you're on your own.
Not sure what you mean; channels don't force you to copy buffers, you can simply pass the pointer/slice through the channel, but the point is that the paradigm encourages you to pass the ownership of that buffer through the channel.
"the paradigm encourages you to pass the ownership of that buffer through the channel."
Rust transfers ownership when you send a single-owner reference over a channel. The sender can no longer access the referenced object; the compiler prevents that. That's the safe way to do it. This is a significant advance in multi-thread programming. The rules that make this work are strikingly simple. Somebody should have thought of this 20 or 30 years ago, but as far as I know, nobody did. Rust pushes the single-owner model hard, and it seems to work. The C++ crowd beat their head against the wall on this for decades, through three generations of auto_ptr, then unique_ptr. Really getting it right requires something like the Rust borrow checker, which C++ does not have.
Go does not do anything to prevent sharing data between threads. It's very easy in Go to unwittingly create shared data, because slices are references. After you've sent a reference, the sender still has access to the shared data, as does the receiver, so there's a potential race condition. Go does nothing to prevent this. There's a lot of dancing around this issue in "(In)effective Go", and long discussions of "is this a race condition" in Go forums. Go is a useful language, but it's in spite of Go's concurrency system, not because of it.
Why can't you transfer buffers as []byte or []float32 etc to another goroutine over a channel? Hint: that doesn't copy the buffer, it just transfers "ownership" of it.
What if the buffer is aliased? In rust, when you transfer ownership, you can statically guarantee that there's no aliasing. But AFAIK that's not possible in go.
"ownership" was in quotes because what he really means is "logical, but not language guaranteed, ownership". Both sides of the channel still can touch the underlying data and cause races.
Don't take this the wrong way, I'm not complaining about Go. Just know that sometimes, there are real reasons to share memory. And when you do: Rust has got your back, but in Go you're on your own.