There isn't one language to rule them all. An advantage of Go over Rust is easier tooling due to a simpler language, an advantage of Rust is a richer type system. These are in opposition.
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.
> 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.
Ygg2|10 years ago
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.
bjwbell|10 years ago
pcwalton|10 years ago
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.)
bjwbell|10 years ago
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.
kibwen|10 years ago
bjwbell|10 years ago
For Rust and Go the example I'm thinking of is rustfmt and gofmt.
ngrilly|10 years ago