Depends how you define it. If you want fine-grained concurrency, in a large and complex program, then Rust can be easier.
Rust itself is not easy to learn, but once you overcome that, its thread-safety features are amazing, and can catch bugs that could otherwise be very difficult to track down. In Golang you're at risk of forgetting to use a mutex or atomic where necessary, or having some function mutate object you thought was immutable, and the race detector needs to catch such violations at run time, whereas Rust catches them at compile time.
Rust has libraries for multi-threaded jobs (like parallel iterators), while in Golang I see people making ad-hoc DIY versions of these with channels and goroutines, and the simple constructs don't always handle cases like cancellation or panics.
Go’s difficulty doesn’t come from being too hard to understand, but from being too simplistic to solve problems properly once.
Repetitive code creates more room for simple mistakes. When every case gets an ad-hoc solution it’s natural to cut corners, because it feels wasteful and too noisy to make every boilerplate copy look complicated by handling edge cases.
So you don’t have `parallel for`. Instead, each instance is a hand-rolled combo of channels that may or may not limit maximum concurrency, may not care to preserve order when items take different time to process, may not finish or report failure correctly when one of the tasks panics.
Additionally, goroutines don’t have any thread safety guarantees. Built-in types aren’t safe to share unsynchronized between goroutines, and the language is too basic to prevent accidental sharing or force immutability or synchronization. A too-easy language can put more burden on programmers.
