Sometimes, yes, using a mutex makes more sense -- and that does introduce the possibility of a data race.
If you follow effective Go code -- I imagine the code is on average about just as safe as Rust code is. It is partially comparable to using `unsafe` blocks in Rust -- don't do it, unless you know what you're doing. Stick with channels.
That said, channels in Rust are also nice to use, and you shouldn't not choose channels. Rust just enables other use-cases too.
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.
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.
The same claim can be made for C++ (with uniqe_ptr<T>), but we know how that faired. It is telling enough that there is a race detector tool for Go.
std::unique_ptr<int> p(new int(1));
std::unique_ptr<int> q = p;
You can strong arm it into break but you can also reuse a pointer locally in Go after it was sent over a channel.
#include <iostream>
auto f() {
int x = 1;
return [&] () { return x; };
}
int main(int, char **) {
std::cout << f()() << std::endl;
}
If you want something particularly involving unique_ptr, consider that best practices are to give non-owning sharing as raw pointers: you could say they're safe as long as you use them correctly but again that misses the point. I can also give an example (stolen from a talk) directly involving shared_ptr even when used with traditional "best practices" although I'm sure the best practices will update themselves to include this.
In some sense, Rust has been described as merely formalizing and automatically enforcing the best practices that people were already using in C++; it's the formality and automaticity that turns it from a dangerous language to a safe one.
My first thought would be to attach the connection object to the data the other thread is working on. When it is done it processing your message it drops the whole thing, closing the connection. If you want to hold it open for multiple workers you could make it an Arc<Connection> so it doesn't close until they all drop it.
Rust has one killer feature that Go does not have: the typesystem has semantics for memory sharing. You can declare how a pointer can be used: is it accessed concurrently, is it local to me, &c. This helps the typesystem detect race conditions where two threads access a block of memory in an unsafe way.
Go does not have this. In Go, you "share memory by communicating", instead of "communicating by sharing memory." But if you do want to share memory, you are back to using locks and your own conventions and mechanics to prevent concurrent access. The language doesn't help you.
So it's a different programming paradigm. And if you use Go like you would use Rust (memory sharing), then Go is less safe.
(...right?)
EDIT: This sounds one-sided, but I'm only talking about sharing memory, here. If you don't do that, and stick to communicating, then Go can blow you away. I don't know how Rust deals with coroutines, but Go has super light threads (goroutines) that make concurrent behavior pure joy. All your threads can so easily talk to eachother, and wait for eachother, and it's all so light and native and good!
E.g. you have a handler for a POST, but you only want to close the connection when another thread has finished doing something. And you don't want to tie up an entire OS thread, because it could take a while and that's just too expensive. In go: super easy, just do a blocking channel read. In another language? Wow, where would I start...
(How does rust do that?)