Hacker News Reader

Comment by marcus0x62 | Hacker News Reader

Meanwhile, over here in the Rust mines, I wrote a simple program that is little more than an http listener with a single route.

Cargo pulled in something like 105 dependencies to build it.

Although, as an apples to apples comparison, it does only have 2 use statements.

View on HN

In case you want to create a simple http listener without dependencies (besides the standard library), the official Rust Book has a tutorial for just that: https://doc.rust-lang.org/book/ch20-01-single-threaded.html

I’m aware, but thank you.

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

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 signal_hook crate even contains documentation on those pitfalls. 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.

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

I should have recognized the username… (Is signal handling even required here?)

And, the meme, for every comment in C or C++ on HN, there is one "but Rust".

we should turn it into a law or somthing...

While we’re making laws, we could add one where, if someone posts something even slightly critical of Rust, the first couple of responses will be from Rust apologists either: a) pointing out how wrong the criticism is, b) how the criticism is mis-directed and shouldn’t be aimed at Rust, or c) how the criticism is really a beneficial and well-thought-out feature, but under absolutely no circumstances admitting that there might be anything wrong with Rust.

No true Rustacean?

https://en.m.wikipedia.org/wiki/No_true_Scotsman

Not sure if that's a good analogy, but put it out there, to see what people say.

This doesn't really surprise me, doing an HTTP service correctly is not actually trivial

Reply on news.ycombinator.com