4 ms·
"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 point
by maeln 4mo ago
"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 problems. 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.
There are many issues that need to be dealt with to mitigate supply chain attacks. A bigger stdlib or an "stdlib-extended" a la Boost, is not one of them.
Also, specifically for Rust, many people run in a no-std environment (anything sized constraint for the most part). So another stdlib would do nothing for them.
- greyw 4mo agoHow is code being "stolen" here? It's FOSS code that is being copied.
- striking 4mo agoTake for example https://github.com/rust-stdx/stdx/tree/main/itoa 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.
- greyw 4mo agoOh wow you are right, thats really bad. Terrible look for the author.
- traceroute66 4mo ago> 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.
- kibwen 4mo ago> 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.
- traceroute66 4mo ago> 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.
- bigstrat2003 4mo ago> 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.
- worik 4mo ago> stealing some code Strong words. Care to back them up?