As with everything, it's a tradeoff. You're right that it's working well with Go, but that's because Go is willing to accept the downsides of that choice. And they've done some stuff to minimize those downsides.
I think both languages made the correct decisions for what they're trying to accomplish as a language.
That solved the hot split problem, but that was more of a once-in-a-while gotcha. The main downside for Rust specifically was the complications that arise when doing any sort of C interop in the presence of growable stacks. This mattered more for Rust than Go, since Rust is relatively more intended to freely intermingle with C code (and other languages via, C FFI), whereas the happy path for Go tends to involve exclusively Go code in a given process (even going so far as to reimplement their own libc in Go), and use of cgo is discouraged by the community (https://dave.cheney.net/2016/01/18/cgo-is-not-go).
It wasn't the right choice for Rust, but that doesn't mean Go's choice was wrong.