5 ms·

The features vs versions graph is more than a little nonsensical, and its conclusions even more so. > They should be stable and move slowly so that most of the

The features vs versions graph is more than a little nonsensical, and its conclusions even more so. > They should be stable and move slowly so that most of the time of your develoeprs is not spent fighting with their tools. I can't speak to Go's tooling base, but Rust's is head and shoulders above any other ecosystem that I've had to work with. This is definitely more a point in Rust's favor than against.

dontlaugh 3y ago
Go’s is ok. Not as good though.
- icholy 3y ago
  Can you provide an example of where rust has better tooling than Go?
  - saghm 3y ago
    Offhand, I like rustfmt a lot more than gofmt because it handles long lines rather than only changing things within a given line; in my opinion, any time I need to manually format something myself, that's a failure of the formatting tool. I also find rustdoc to be much more flexible than Go's documentation functionality (which I forget the name of, but I assume it's something like `go doc`). At least the last time I used it Go required me to prefix any doc comment for a given function, type, etc. to start with the name of the item I was documenting; not only is this redundant, but it also means that any typo I make will cause the comment to be omitted completely, whereas Rust only requires a third slash for doc comments (i.e. `///` rather than just `//`). It's a minor thing, but small quality of life things add up across an entire ecosystem.
    - icholy 3y ago
      Prefixing doc comments with the ident name is a convention that isn't enforced in any way. You must have been using a 3rd party linter.
      - saghm 3y ago
        So any comment that happens to be right before a public type, function, etc. is exported into documentation without any special syntax needed? Honestly, in my opinion that's even worse, given that part of the whole point of tools like this is to generate public-facing documentation for websites; I want doc comments to be visibly different than regular comments, but it sounds like the only thing that would determine whether a comment is exported is the surrounding context.
        icholy 3y ago
        You're just making problems up now ...
throwawa14223 3y ago
At the hobby level in Rust I am constantly in awe of how good the Rust tooling is.
eikenberry 3y ago
Go's tooling is much better in one key aspect, compile times. Rust's compile times and feedback loop are terrible and it is not a community priority (ie. they want to make it faster, but only incrementally and not the orders of magnitude improvement it needs). Go's could be better but at least it is a priority.
- emi2k01 3y ago
  Rust's compile times are worse than Go but are still way better than people make it to be. Here are some examples: --- Rust Analyzer: Clean build: 31.02s Incremental build: 3.07s (Added a `println!` in a level-2 dependency in the dependency graph) SLOC: 306,467 SLOC of dependencies: ~879,304 (After removing `win*` packages which make up for another 1.3M) --- Zola: Clean build: 24.58s Incremental build: 1.34s (Added a `println!` in a level-2 dependency in the dependency graph) SLOC: 17,233 SLOC of dependencies: ~2,087,781 (After removing `win*` packages which make up for another 1.3M) Obviously, not all source code gets compiled due to conditional compilation but it makes for a good approximate if you only take into account 2/3 of it. --- For comparison with Zig by building ZLS: Clean build: 20.13s Incremental build: 10.27s (I believe this builds the ZLS package again from scratch so not really incremental) SLOC: 45,806 SLOC of dependencies: I don't know how to get this. --- This was on a Ryzen 5600x

dontlaugh 3y ago

Go’s is ok. Not as good though.

icholy 3y ago
Can you provide an example of where rust has better tooling than Go?
- saghm 3y ago
  Offhand, I like rustfmt a lot more than gofmt because it handles long lines rather than only changing things within a given line; in my opinion, any time I need to manually format something myself, that's a failure of the formatting tool. I also find rustdoc to be much more flexible than Go's documentation functionality (which I forget the name of, but I assume it's something like `go doc`). At least the last time I used it Go required me to prefix any doc comment for a given function, type, etc. to start with the name of the item I was documenting; not only is this redundant, but it also means that any typo I make will cause the comment to be omitted completely, whereas Rust only requires a third slash for doc comments (i.e. `///` rather than just `//`). It's a minor thing, but small quality of life things add up across an entire ecosystem.
  - icholy 3y ago
    Prefixing doc comments with the ident name is a convention that isn't enforced in any way. You must have been using a 3rd party linter.
    - saghm 3y ago
      So any comment that happens to be right before a public type, function, etc. is exported into documentation without any special syntax needed? Honestly, in my opinion that's even worse, given that part of the whole point of tools like this is to generate public-facing documentation for websites; I want doc comments to be visibly different than regular comments, but it sounds like the only thing that would determine whether a comment is exported is the surrounding context.
      - icholy 3y ago
        You're just making problems up now ...

throwawa14223 3y ago

At the hobby level in Rust I am constantly in awe of how good the Rust tooling is.

eikenberry 3y ago

Go's tooling is much better in one key aspect, compile times. Rust's compile times and feedback loop are terrible and it is not a community priority (ie. they want to make it faster, but only incrementally and not the orders of magnitude improvement it needs). Go's could be better but at least it is a priority.

emi2k01 3y ago
Rust's compile times are worse than Go but are still way better than people make it to be. Here are some examples: --- Rust Analyzer: Clean build: 31.02s Incremental build: 3.07s (Added a `println!` in a level-2 dependency in the dependency graph) SLOC: 306,467 SLOC of dependencies: ~879,304 (After removing `win*` packages which make up for another 1.3M) --- Zola: Clean build: 24.58s Incremental build: 1.34s (Added a `println!` in a level-2 dependency in the dependency graph) SLOC: 17,233 SLOC of dependencies: ~2,087,781 (After removing `win*` packages which make up for another 1.3M) Obviously, not all source code gets compiled due to conditional compilation but it makes for a good approximate if you only take into account 2/3 of it. --- For comparison with Zig by building ZLS: Clean build: 20.13s Incremental build: 10.27s (I believe this builds the ZLS package again from scratch so not really incremental) SLOC: 45,806 SLOC of dependencies: I don't know how to get this. --- This was on a Ryzen 5600x