A richer type system is not in opposition to good tooling, quite the opposite. Rust's strong type system enables fantastic static analysis, which, for example, obviates the need for anything like Go's data race detector.
Writing tooling for C++ is difficult because of how entangled all the language's features are (and its wonky grammar certainly doesn't help). In addition C++'s type system is probably even weaker than Go's, having inherited a lot of slop from C.
That said, if you're talking about source code formatters, I'm pretty sure that clang-format predates gofmt (and surely clang-format was not the first automatic source code formatter for C++). The coup for Go was that they got the community at large to standardize upon and champion gofmt, which is not something that C++ has ever matched.
I'm thinking more of difficulty in writing rustfmt compared to gofmt. There's other examples like go-oracle or goimports which as far as I know don't have Rust equivalents.
How useful the extra tooling is, I don't really know.
>
I'm thinking more of difficulty in writing rustfmt compared to gofmt.
The extra stuff that rustfmt does stems from the fact that rustfmt wants to aesthetically format code well, matching the style that the community had settled on prior to its introduction (e.g. avoiding long lines, lining up parameters), while gofmt is fine with less aesthetically pleasing code (long lines, all parameters on one line) as long as the implementation of gofmt remains simple. There's nothing stopping anyone from implementing a bare-bones rustfmt in the style of gofmt and trying to push its style onto the community, but Nick had different goals.
You're right, the comparison isn't as valid as I thought, rustfmt has improved impressively since I looked at it last. 'go fix' might be a better comparison, what's the Rust equivalent?
For Rust and Go the example I'm thinking of is rustfmt and gofmt.