Eh? Rust tooling is excellent?

Rust can reuse nearly all C tools like kcov, gdb, perf, valgrind. On top of it, it has a solid set of its own tools. For example it has rustfmt, cargo, rustdoc (having the ability to test your Rust documentation is great).

Only thing it truly misses is a IntelliJ IDE for Rust and possibly a Rust oriented coverage system.

I'm familiar with Rust's tooling, not knocking it at all.

> An advantage of Go over Rust is easier tooling due to a simpler language

I'm curious how "tooling" is easier in Go than in Rust. To my mind, dynamic tooling (instrumentation, profiling, debugging, etc.) is much easier in Rust than in Go, because Rust uses the OS facilities and looks much like native code, while Go's runtime reinvents the world.

This is in fact what we've seen—Rust didn't have to write custom profilers, custom debuggers, language-specific race detectors, and so on, because the native system tools work just fine.

(NB: I'm not saying Go made the wrong decision with a userland scheduler; I'm objecting to the idea that it's somehow simpler to do that. It's much more complex.)

I should have been more specific by tooling. I meant source code manipulation and analysis, go-oracle and goimports are a couple. There's many more in the go community.

Are they useful, I'm not sure. They feel useful but I have little trust in my judgment. When I switched back in the day from VS to emacs I didn't seem to miss all of the refactoring tools VS provided.

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.

Perhaps I should have said it's easier to write tooling. C++ has arguably very good tooling but creating it was difficult.

For Rust and Go the example I'm thinking of is rustfmt and gofmt.

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?

We don't make breaking changes anymore, so the need for such a thing hasn't been enough for anyone to bother making it.

One thing that can make tooling difficult in Rust are macros.

Indeed, though macros are not a feature of the type system. :)

Agreed :-)