Hacker News Reader

Comment by jimbokun | Hacker News Reader

Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients:

https://medium.com/@shnatsel/smoke-testing-rust-http-clients...

Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article.

Here is the first one I clicked on:

https://github.com/algesten/ureq/issues/24

The maintainer is happy to get the report, and has an exchange with the reporter acknowledging the bug and how to fix it.

This all seems a very civil, mature way to address issues with open source software. Accept actionable criticism of your code, and strive to make it better. As a developer, I know having other people test my code and report problems back to me is one of the best ways for them to help me and my code improve!

I think identifying to your code to the point where you consider criticism of your code an attack on your personal identity demonstrates a real lack of maturity.

View on HN

You might have missed a couple lines. It's easy to miss as it's right below the quote from the article mentioned: "This causes the now-usual Reddit uproar. It’s extra nasty this time. Some people go far, far, far over the line."

The issue isn't the article or the bug reports. It's the uproar from Reddit, and the extra nasty comments.

"Some people go far, far, far over the line."

There is a reason HN has guidelines for how to approach communication. It's because if we "go far, far, far over the line" and get "extra nasty" things devolve and this place becomes far worse. Rather than "toughen up" or "just not taking things personally," HN realizes that words matter.

Like I said, a couple lines easily missed or forgotten. It's not the bug reports. It's the extra nasty comments.

This could very well be thanks to the moderators, but I hardly saw any nasty comments on r/rust. People were critical of the actix maintainer, sure, but I didn't see anything that crossed the line. Some comments in the GitHub issues were indeed nasty, but those were actually called out on the subreddit.

There's no way for me to know for sure, but it seems as though Klabnik was exaggerating here.

The nastiest response I encountered was at the end of the GitHub issue thread, right before the maintainer deleted it. (He also cites it in his postmortem.) It said things like "you should never write Rust again," with very little substance.

The problem with the r/rust thread, AIUI, is less "far, far, far over the line" and more just a huge volume of the same sorts of criticism. It sucks to see such a response on that scale, but it's harder to characterize any individual's comment as "nasty."

Yeah, that comment on the GitHub issue was definitely over the line, but it wasn't on Reddit. The comments in the subreddit were higher in volume, but way more reasonable.

Well, I've certainly seen some nasty behavior in topics touching the async-std crate that I didn't like and thought should not be written. It felt really bad and was the first time I felt how this community has changed from the years I started writing Rust.

>> It felt really bad and was the first time I felt how this community has changed from the years I started writing Rust.

I agree. I'm further disheartened by a lot of the reactions that happened since. One of Rust's greatest strengths is turning into a weakness.

The Rust community needs to treat this cultural exploit as if it were a critical technical exploit and apply the same sort of objective and collective examination of source and insightful exploration of assumptions made about existing grammars and syntax and come up with appropriately safe and forward thinking solutions to ensure that the code of conduct isn't just a progressive cliche.

Here's the thing, though: you're looking at a very limited set of interactions (namely, n=1), and declaring that the developer of ureq is awesome and polite, and that the developer of actix is an asshole.

You don't know the history of either project, or either person. The developer of ureq probably has some bad days and responds in ways that their not proud of. The developer of actix has probably had some (many?) good days and responded politely and helpfully.

Indicting the actix developer given a small set of responses to a particular class of issues is a bit unfair.

There is a difference in the bug reports: The ureq one shows a proven error - a crash. That's bad, the author acknowledges it and fixes it.

The actix issue does not show an actual error. It just tells that some internal code does not follow the usual Rust unsafe conventions, and that this might lead to a bug. It takes then some API exploitation by a third person to demonstrate how this could lead to a bug. At that point the author acknowledges the issue, even though any real world implication is still unknown.

> Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients:

Interesting. I'm being led to believe that the actual problem lies in HTTP itself: it is too convoluted to be safely implementable and should be replaced with something else for security-critical applications. (Or in general.)

I don't think this is true. In fact, today, I privately forked one of the aforementioned libraries (httparse) and removed all of the unsafe parts in under an hour (without introducing any new memory allocations, I might add). All the tests pass.

It's not insurmountable. It just takes a little bit of elbow grease and self-discipline ;)

While this may or may not be true, it's irrelevant to the use of “unsafe” code in Rust. Rust doesn't attempt a compile-time guarantee that your code is simple or bug-free. It attempts to guarantee that mutable aliasing, use-after-free, double free, and resource leaks don't happen. No wire protocol requires such things or is even relevant to them.

But this is a problem Rust creates for itself. HTTP is safely implementable in most modern languages without any unsafe code because they're all garbage collected. For instance, Java has a mechanism also called Unsafe that lets you bypass the language's safety features, but I've never encountered an HTTP client that uses it because performance is fine without that. And the JVM developers have been working for years on safe but performant constructs that can replace the uses of Unsafe that do exist in the community, mostly, cases where very precise control over memory and concurrency constructs are needed in high performance servers.

Reply on news.ycombinator.com