Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why stdx is not on crates.io

kerkour.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Why stdx is not on crates.io

#41

Post by traceroute66 »

ameliaquining wrote: post #40
traceroute66 wrote: post #31

Earlier quoted context omitted.

> 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 vulnerab…

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 se…

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

Re: Why stdx is not on crates.io

#42

Post by oefrha »

tialaramex wrote: post #34
deeebug wrote: post #6

Earlier quoted context omitted.

Looks like it's that, plus vibe coding (in areas like crypto!) - https://kerkour.com/stdx

The whole "There are test vectors so we know it's correct" is a strong sign that this isn't actually safe to use and that indeed the people who built it (to the extent people actually did build it) have no idea what they're doing.

To save you a read of the original while still having enough context, here's the whole section on crypto:

> crypto: spec and test-driven development to the rescue

> Cryptographic code is famously hard, with many, many footguns haunting unsuspecting developers (and even experts!).

> But, cryptography also has something that you likely won't find in any other domain: an extensive public collection of test vectors, particularly for edge cases. Every algorithm specification come with a basic suite of test vectors, but there are also community-built wonders such as Wycheproof.

> These test vectors, combined with the official specification documents of the crypto algorithms were rather effective to guide the coding agents and avoid the worst hallucinations.

> Cost: ~ $30

> Time: multiple days of part-time work.

> I'm under no illusion that the crypto crate is currently bug-free, but if my experience told me anything, it's that even experienced programmers are shipping bugs in crypto libraries. So, for similar outcomes, but using 1/100 of the time and at maybe 1/1000 of the cost, I think it's a clear demonstratin of AI's effectiveness.

Yeah, terrifyingly clueless, don't use.

Re: Why stdx is not on crates.io

#44

Post by bigstrat2003 »

maeln wrote: post #22

"The solution to rust's supply chain woes is me stealing some code and vibe coding the rest" is truly one of the take of all time. And in general, people pointing at Rust "limited" stdlib (it's only limited compared to Python) as one of the big issue and risk with rust are, in my opinion, misguided. You will never make an stdlib big enough to remove the need for external dependencies. It also creates a bunch of other…

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

Re: Why stdx is not on crates.io

#45

Post by sfdsfef3f3f »

ameliaquining wrote: post #40
traceroute66 wrote: post #31

Earlier quoted context omitted.

> 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 vulnerab…

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 se…

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.

Re: Why stdx is not on crates.io

#46

Post by andriy_koval »

NoboruWataya wrote: post #35

Namespace pollution is an annoying problem in Rust. A while ago I was looking for a crate to help build something to interact with Apache Solr. Great, there's a Rust crate called `solr` on crates.io. And here it is: https://github.com/lambdastackio/solr-rust There are other examples of crates registered on crates.io with prominent names that are just stubs with one commit from years ago. I'm sure this problem also ex…

If you sort by recent downloads, you find that https://crates.io/crates/solrstice looks likely most popular

Re: Why stdx is not on crates.io

#47

Post by kibwen »

traceroute66 wrote: post #38
kibwen wrote: post #37

Earlier quoted context omitted.

> 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 comprehe…

> 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-t…

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

Re: Why stdx is not on crates.io

#48

Post by EnPissant »

traceroute66 wrote: post #31
maeln wrote: post #22

"The solution to rust's supply chain woes is me stealing some code and vibe coding the rest" is truly one of the take of all time. And in general, people pointing at Rust "limited" stdlib (it's only limited compared to Python) as one of the big issue and risk with rust are, in my opinion, misguided. You will never make an stdlib big enough to remove the need for external dependencies. It also creates a bunch of other…

> 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 vulnerab…

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

Re: Why stdx is not on crates.io

#49

Post by insanitybit »

NoboruWataya wrote: post #35

Namespace pollution is an annoying problem in Rust. A while ago I was looking for a crate to help build something to interact with Apache Solr. Great, there's a Rust crate called `solr` on crates.io. And here it is: https://github.com/lambdastackio/solr-rust There are other examples of crates registered on crates.io with prominent names that are just stubs with one commit from years ago. I'm sure this problem also ex…

How do namespaces help? I'm building a package registry and I've decided against namespacing because I can not see how to implement it in a way that doesn't just lead to even worse problems.

Re: Why stdx is not on crates.io

#50

Post by tialaramex »

kibwen wrote: post #47
traceroute66 wrote: post #38

Earlier quoted context omitted.

> 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-t…

> 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 datastruct…

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.

Post reply on HN