Yes, experience in both. I'm considerably more inclined to use Rust for any use case, but I'll freely admit that I'm biased because it appeals to my sensibilities more.
IMO the most compelling use case to use Go over Rust is if you're writing a networked service or networking code.
Having used both Go and Rust for networked and networking code, I'd say it's a pretty nuanced set of tradeoffs between the two.
I've written a couple protocol handlers in rust (that is parse the packet and handle the logic before giving the data to some other bit of code) and I found Rust really nice for that - real enums, pattern matching, and the use of traits can make interacting with binary protocols (particularly of the state machine variety) really nice with ergonomic interfaces. Meanwhile go's net/IP type (etc) often leave me frustrated.
On the other hand, goroutines and channels are such a nice way to handle a lot of message passing around a server application that I find myself reaching for mpsc channels and using tokio tasks like clunkier goroutines in rust often.
I think I'd draw the line more along "how often I need to work with byte arrays that I want to turn into semantic types" - if I'm going down to the protocol level and not doing a ton of high level logic I'll reach for rust, if it's more high level handling of requests/responses (http for example) I'll often reach for go.
(like the parent, I'm more inclined to reach for Rust over go if all else is equal, but I enjoy go too).
> find myself reaching for mpsc channels and using tokio tasks like clunkier goroutines in rust often
My experience so far with mpsc/tokio tasks is that Fearless Concurrency TM is pretty solid. There is some clunkiness (mostly inconsistency around async styles), but I've been bit by bad channel usage in golang enough times that rust felt refreshing.
IMO the most compelling use case to use Go over Rust is if you're writing a networked service or networking code.