3 ms·

This is a culture problem, not a language problem. Here is a http health check in 19 lines using only the rust standard library. https://dpaste.org/f895z http

by lrvick 3y ago

This is a culture problem, not a language problem. Here is a http health check in 19 lines using only the rust standard library. https://dpaste.org/f895z https://dpaste.org/f895z

marcus0x62 3y ago
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.)
- kqr 3y ago
  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.
  - marcus0x62 3y ago
    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.
    - kqr 3y ago
      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.
- deleted 3y ago
  [deleted]
rezonant 3y ago
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.
- lrvick 3y ago
  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.
  - liftm 3y ago
    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 signal_hook crate even contains documentation on those pitfalls. https://docs.rs/signal-hook-registry/1.4.1/signal_hook_registry/fn.register.html#safety https://docs.rs/signal-hook-registry/1.4.1/signal_hook_regis...) I mean sure, reinvent the wheel. But it might do good to at least have an inkling what those 105 dependencies for your http listener did.
    - lrvick 3y ago
      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. https://dpaste.org/z1cAz https://dpaste.org/z1cAz

by lrvick 3y ago

This is a culture problem, not a language problem. Here is a http health check in 19 lines using only the rust standard library. https://dpaste.org/f895z https://dpaste.org/f895z

marcus0x62 3y ago

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

kqr 3y ago
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.
- marcus0x62 3y ago
  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.
  - kqr 3y ago
    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.
deleted 3y ago
[deleted]

rezonant 3y ago

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.

lrvick 3y ago
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.
- liftm 3y ago
  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 signal_hook crate even contains documentation on those pitfalls. https://docs.rs/signal-hook-registry/1.4.1/signal_hook_registry/fn.register.html#safety https://docs.rs/signal-hook-registry/1.4.1/signal_hook_regis...) I mean sure, reinvent the wheel. But it might do good to at least have an inkling what those 105 dependencies for your http listener did.
  - lrvick 3y ago
    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. https://dpaste.org/z1cAz https://dpaste.org/z1cAz