Hacker News Reader

> it's only limited compared to Python

Erm ....

Its limited compared to Go as well.

And that's a BIG deal because Go gives you single binaries with a stdlib that allows you to hit the ground running in a serious manner.

For example, making API calls which is the sort of thing many here do for their bread and butter. Everything you need to do can be don in Go stdlib without opening yourself up to supply chain vulnerabilities or having to choose which crate or having to keep track of crates versioning. The same could be said of crypto or hundreds of other things present in the Go stdlib.

> Its limited compared to Go as well.

It depends on perspective. Go is tailored for writing backends, so it's great that it provides things like net/http (we could also interpret cause and effect inversely here; Go provides net/http so it gets used for writing backends). Rust's standard library is actually pretty damn huge, but it doesn't index heavily into specific applications, and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it. Rust's stdlib is "small" if all you want to do is build a webserver and don't want to go shopping around for libraries, but anyone who's intimately familiar with Rust's stdlib can tell you for a fact that it's absolutely not small in absolute terms. Rust literally stabilizes hundreds of new stdlib functions per year.

> and instead tries to provide comprehensive support for low-level operations that enable you to build a custom-tailored solution to whatever you need on top of it

So in other words Rust forces you to either (a) re-invent the wheel (yet again !) or (b) import yet-another-crate into your project.

Of course if you choose (b), then its having first wasted your time deciding which of hundreds of yet-another-crate-doing-the-same-thing you want to import.

Its a waste of time and effort for the majority of projects where you are not working with embedded systems or trying to squeeze every micro-second of performance out of your system.

Sadly the majority of Rust projects show exactly zero import discipline, both from a pure import perspective and a security perspective. Which is why many Rust projects end up importing a gazillion crates.

Import discipline in Rust is hard work. Sure you can reach "reasonably necessary" level of imports the majority of Rust projects simply don't bother because its such a pain in the backside.

Don't get me wrong, Rust has its place in this world. But for many people on many projects they would be better off using Go and only using Rust where there is actually a serious use-case for it in their environment.

> Rust forces you to either (a) re-invent the wheel (yet again !)

This is inherent to the domain of systems programming. One-size-fits-all solutions only suffice until you need extreme performance. So, for example, Rust provides a basic hashmap in the stdlib, and as a generalist hashmap it's quite close to state-of-the-art. But as a generalist hashmap it's also beaten in specific applications by specialist datastructures, and Rust needs to provide support for building those specialist datastructures in a way that makes them feel just as first-class as what the stdlib provides.

Go gets away with what it does because it's for domains where it's acceptable to trade uniformity for performance. This is not a bad thing! Go is quite performant. But Rust ultimately isn't competing with Go, it's competing with C.

And note that I say all this as someone who is, in fact, a stdlib maximalist. But I also say all this as someone who is conscientious and informed of the realities of what it takes to design and maintain a secure, high-performance stdlib.

Yeah, not long ago on HN I read into somebody who really wanted a type that's a list of blocks which expands and shrinks only by whole blocks. Such a type would have amortized O(1) push at one end, like Vec, and also amortized O(1) pop - but with much smaller and more frequent allocations, and the index access is horrible, but it would only ever be over-allocating by a bounded amount, this is a relatively inconvenient type for a lot of purposes which is why AFAIK nobody provides this out of the box, but it did suit their needs.

Lest people imagine Rust has so few collections because nobody offered any others, Aria has a rant in her Linked Lists "tutorial" where she explains that pre Rust 1.0 she was cleaning out all the miscellaneous collection types few people need - and she tried but failed to remove the linked list type. There's some very niche types in her list, things I've heard of but never used in decades of professional software engineering.

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.

> 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.

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.

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.

Rust gives you statically linked binaries as well.

So your argument boils down to having to add `reqwest = "0.13.3"` to your `Cargo.toml`.

I don't know of anyone accessing a database like Postgres with just the stdlib in real apps. Or maybe the API is just serving data out of a JSON file checked in the repo?

I agree the stdlib is great but the reality is production apps cannot be built using only it.

Most codebases have dependencies. Most accept dependency updates from renovate etc without much thought. Go can remain secure if goproxy has thorough security scans (I think they do but am not sure if it's unbeatable) and if the fact that any attack will be in OSS code itself, rather than packaged just-in-time in a workflow, makes it visible before significant damage. I have no idea if the latter is true but it might be. Of course NPM packages are just as visible as long as someone is scanning them so maybe not.

> Actually, to take Python as an example, some functionality being in the stdlib have created a bunch of issue over the years since you can't just introduce breaking changes in an stdlib as easily. Look at urllib2/3 or xml in python. In the end, almost everyone ends up using requests and lxml instead.

And yet, I've been in situations where the only thing I had was urllib2, and I was very grateful it existed. It's awesome that the Python stdlib has everything it does, even if most of the time a pypi package is going to be superior.

How is code being "stolen" here? It's FOSS code that is being copied.

Take for example https://github.com/rust-stdx/stdx/tree/main/itoa. Its licenses and copyright information have been stripped. You are permitted to make copies of code under the MIT license, but the license also includes:

> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

If the original repo were to disappear, it would be important to know who wrote the code and what the license actually is.

Oh wow you are right, thats really bad. Terrible look for the author.

> stealing some code

Strong words. Care to back them up?