Hacker News new | ask | show | jobs
by ameliaquining 6 days ago
This is mostly only true if you're writing a network service or maybe a CLI tool. Which is fair enough, since that's what Go is primarily for, but Rust aims to be, not just usable, but the best option, in a broader variety of domains. It wouldn't be feasible to have a batteries-included stdlib for all of them. (Python historically tried, and the results have been rather famously unsatisfactory.)

Also, even network services benefit from things like OpenAPI for type safety, and you don't get that from the Go stdlib.
2 comments
sfdsfef3f3f 6 days ago
A huge portion of the Go standard library is extremely low quality as well. flag, container, image, json, log, much of math, path, regexp, sync and time are all notoriously low quality and will almost certainly get improved versions similar to encoding/json/v2. The container package alone has to be the worst package included with any major programming language in history. The standard library in general is also riddled with abstractions that don't hold across the various platforms that they claim to support. path and os are particularly awful in this regard.

Also if you go look at any real Go projects they usually use tons of dependencies and they're usually pinned to random git hashes which is its own massive problem.

link
quacker 6 days ago
if you go look at any real Go projects they usually use tons of dependencies and they're usually pinned to random git hashes

No, they are usually pinned to a git tag, which is usually a version string representing a released version. And the tag is locked to a hash to detect if the tag is later modified.

link
traceroute66 6 days ago
> even network services benefit from things like OpenAPI for type safety, and you don't get that from the Go stdlib.

Sure, but the point is for the majority of people writing stuff in Go, they can get 99% of the way there with the Go stdlib.

Then, if they need to import one or two things to help them, such as the AWS Go SDK or whatever, that's perfectly fine.

It still means you end up with a go.mod file that has literally only two or three third-party imports in it.

Meanwhile if you wanted to write the equivalent tool in Rust, if you don't care you'll quickly end up with a Cargo.toml measured in hundreds of lines.

And if you are willing to put in the hours to hand-cherry-pick and make your Rust imports "reasonably necessary", then you'll still have a whole bunch more third-party imports than the Go equivalent.

link