Live data from Hacker News

Stdx, Rust's extended standard library

kerkour.com

11–19 of 19 posts

Re: Stdx, Rust's extended standard library

#11
My personal preference would be to avoid a project whose maintainers push vibe-coded commits with one-line messages like "crypto: accelerate aes256" [1], especially when said commits introduce large blocks of unreadable inline assembly!

[1]: https://github.com/rust-stdx/stdx/commit/550c11b75804392e366...

Re: Stdx, Rust's extended standard library

#12

...but why? Seriously, this needs some more justification: > Only big and well-funded organization are able to build the internal tooling and libraries requireed to securely ship large Rust projects. Leaving aside the (real!) problems other commenters have highlighted, before even getting to those issues I have a small foundational question: Is this actually a real problem?

The proposed solution conflicts with the supposed problem.

The author is an individual claiming the ability to author and maintain a standard library

… to be used by small orgs who do not have the resources to author and maintain a standard library.

Re: Stdx, Rust's extended standard library

#13

This is a collection of forked open source crates bundled together with open model vibe coding? > the code written by AI is more robust than by humans because more edge cases are tested. This is at least a mildly concerning take to see in a blog post announcing a solution to supply chain security. It seems like this boils down to: don’t trust the original authors to maintain the packages they wrote, trust me and my L…

This whole article is red flags. (Mental health issues including narcissism?)

  - No mention of what specifically it does
  - No mention of the advantages and stated reasons for having small std and core libs
  - Libs mentioned as being "shipped" by the author have no commits by him or her.
  - No comparison in the specifics to how it's handling
  - Uses phrasing which might (IMO deliberately) confuse people into thinking this is official.

Re: Stdx, Rust's extended standard library

#14

...but why? Seriously, this needs some more justification: > Only big and well-funded organization are able to build the internal tooling and libraries requireed to securely ship large Rust projects. Leaving aside the (real!) problems other commenters have highlighted, before even getting to those issues I have a small foundational question: Is this actually a real problem?

[deleted]

Re: Stdx, Rust's extended standard library

#15

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

Test vectors won't protect you against side-channels. This guy is a walking illustration of Dunning-Kruger, and calling it "Rust's extended standard library" as if it has any kind of official status is just deranged.

Re: Stdx, Rust's extended standard library

#16

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

Here it's important to take into account the consequences / cost of false positive vs false negatives.

If you're building a dashboard for visualizing something fun (hot dog sales in sport games) then the corner case error has low cost. I'm happy having this vibe coded dashboard that works 99/100 and my world is better with it existing.

Crypto is on the opposite scale (and I'm surprised this blog doesn't realize it): 9999/10000 isn't good enough because the corner cases have dire consequences. So, yeah, bad example for vibe coding

Re: Stdx, Rust's extended standard library

#17

...but why? Seriously, this needs some more justification: > Only big and well-funded organization are able to build the internal tooling and libraries requireed to securely ship large Rust projects. Leaving aside the (real!) problems other commenters have highlighted, before even getting to those issues I have a small foundational question: Is this actually a real problem?

The proposed solution conflicts with the supposed problem. The author is an individual claiming the ability to author and maintain a standard library … to be used by small orgs who do not have the resources to author and maintain a standard library.

Yeah it's a fractal of wtf all the way down..

Re: Stdx, Rust's extended standard library

#18
I like the idea of an extended standard lib for Rust, but coding was never the hard part. The hard part is getting everyone to agree what should be in it. If you can get everyone to agree to an api then the rest can easily be filled in (with or without vibe coding).

Re: Stdx, Rust's extended standard library

#19
IIUC this just pulls in various other crates with some vibe-coding on top. I'm not familiar with the Rust dependency system, but what is the need to have copies of the code? Would it not suffice to just have an "empty" crate that just depends on the original crates?
Post reply on HN