Hacker News Reader

Comment by seurimas | Hacker News Reader

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.

View on HN

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.

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

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

Go’s is ok. Not as good though.

Can you provide an example of where rust has better tooling than Go?

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.

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.

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.

You're just making problems up now ...

Reply on news.ycombinator.com