There’s a lot of distance between “reinvent the wheel by implementing all your network functionality using nothing more than sockets” and “download 100 libraries to serve a file over http”.
There’s a happy medium to be had.
I’d also disagree this is not at all a language problem - I think it’s both, in that the language has moved an awful lot of core functionality into the crate ecosystem, where there are a bewildering array of options for almost any need. The resulting explosion in the dependency graph is an entirely foreseeable consequence — partially of that language design decision and partially due to the “npm culture” (for lack of a better description.)
Slighly off topic, but... how is npm culture different from CPAN culture? I have a feeling there is a difference but I'm too unfamiliar with both ecosystems to point it out.
Speaking as someone who used Perl pretty extensively back in its heyday I’d say the difference is CPAN modules were much more likely to be self-contained, or contain a handful of external dependencies, and those dependencies were almost always self-contained.
Aah, that makes a tonne of sense. When you develop an application you're free to pull in any libraries you want, but the libraries themselves should be more careful. For them, it might be worth reimplementing some essentials.
Sure, if you are putting in a health check and nothing else, that's fine. When you need to parse headers, negotiate content types, validate maximum lengths on requests, properly log the source of the request (it's not just the connecting IP if there's a load balancer in front of it), parsing request bodies, dealing with range requests, authentication, cookies, providing a good middleware mechanism...
The list goes on. While I'm not a Rust developer, there's probably hundreds of libraries because the problem is structured into a lot of small parts, and frameworks are expected to be able to satisfy the functionality you expect without needing to bypass it.
As a security engineer it is still usually cheaper to write specific functions I need for highly limited scope applications than pull in libraries I have to review, and review every update to, forever.
I've seen this attitude before. In that specific case, someone tried to not depend on the signal_hook crate and manually (unsafely) implement signal handling… without knowing that there's a ton of pitfalls to it.
The person you are referring to was likely also me. I do not know of anyone other than me trying to code defensively against supply chain attacks in rust. It is a lonely corner.
I ended up going with sigwaitinfo since the attempts you likely saw on matrix which is perfect for my application that will only ever run on modern linux kernels.
Combining that with the stdlib health check above and we end up with a dead simple health checking signal handling service pattern that works well and easy to confirm is free of supply chain attacks.
Here is a http health check in 19 lines using only the rust standard library.
https://dpaste.org/f895z