A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#841

Post by roca » Fri, Jan 17, 2020, 10:14 PM UTC

joeblau wrote: post #574

I want to give a heads up to everyone who runs, or is thinking about running an open source project. If your project sees ANY notoriety and you are the maintainer, you will quickly find yourself in this situation. In 2013, I started a little side open source project and put it on GitHub which now has 5.2k stars. I've seen tons of arguments in my PR's over the previous 7 years. My project isn't even that large and I'v…

It must depend on the project in ways I don't understand. Certainly while working on Firefox I saw tons of toxic behavior from users, and sometimes potential contributors. I've seen it in lots of other projects that I haven't worked on. But for rr (4.7K Github stars) I have seen none whatsoever. I wish I could explain the difference, but I can't.

Re: A Sad Day for Rust

#842

Post by Rusky » Fri, Jan 17, 2020, 10:16 PM UTC

timjver wrote: post #777

jasonlotito wrote: post #183

Earlier quoted context omitted.

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 fo…

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

Re: A Sad Day for Rust

#843

Post by kllrnohj » Fri, Jan 17, 2020, 10:16 PM UTC

khazhoux wrote: post #663

kllrnohj wrote: post #503

Earlier quoted context omitted.

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. It is when they setup an open source project that has that appearance and is framed as being such a project. It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant…

> It is entirely the maintainer's responsibility to establish the type of open source project it is. On what basis does a developer assume this responsibility? You are saying that by uploading a library that works well, and whose presentation (docs, etc) are high quality ("professional") that the owner now has the responsibility to publicly state whether this is a personal project or not, and they must state their SL…

> You are saying that by uploading a library that works well, and whose presentation (docs, etc) are high quality ("professional") that the owner now has the responsibility to publicly state whether this is a personal project or not, and they must state their SLA and process with respect to accepting patches?

No, I'm not. I'm saying if you setup an open source project framed as a project that is production ready & open to patches with a guise of being run by an organization and intentions of having a community, then it is reasonable to expect that you actually do that. You don't accidentally make a github organization, after all. There are community norms around what you can expect when working with such projects. Particularly when then both the github page and the webpage speak of being welcome to contributions ( https://github.com/actix/examples#contribute ) and building a community.

This was not just a high-quality library tossed out into the wild that got adoption. This is a library complete with these pages https://actix.rs/community/ & https://actix.rs/code/

The author did a hell of a lot more than just "uploading a library" here. As such, the developer assumes these responsibilities because it's what they said.

You are always responsible for what you broadcast.

Re: A Sad Day for Rust

#844

Post by dnorman » Fri, Jan 17, 2020, 10:18 PM UTC

zozbot234 wrote: post #788

Traster wrote: post #775

Earlier quoted context omitted.

'Crappy' and 'Hacked-together' are literally just insults, they don't carry real technical criticism and frankly they just continue to undermine the credibility of the author. The fact is that 'crappy' code is the most used http crate by far. Clearly everyone in the rust community must be an idiot to be using it. I'm sure the author went off and wrote a totally safe replacement for it. See, now we all get to be dicks…

The first step in working to fix stuff is being aware of the issues - there's nothing "insulting" about that. Unsafe blocks without any clearly-stated rationale and safety analysis is quite subpar quality. Just because it's common and a "most used crate" does not make it OK, leftpad was widely used too.

_It's not what you say but how you say it_

With all due respect, you are not the universal arbiter of "crappy"-ness and "hacked-together"-ness, nor is anybody else. My guess is that you have concerns about the library, and you are absolutely within your right to say so. Your concerns may even have significant substance to them; or perhaps there is additional perspective that could change your mind.

Unfortunately, presenting your view and judgement as a statement of objective fact not only shuts down potentially valid counter-argumentation, but it's also inflammatory/insultory because it misrepresents your agency in the situation, and diminishes the efforts/personhood of those who contributed to the library.

It's understandable that you might want to use such phrasing as short-hand from time to time, but saying it out loud, especially in a public venue is regrettably demonstrative of a lack of self-awareness. It drowns out your message regardless of its merit, and pushes other people away. It's a reductive way of thinking, and it does everybody (including yourself) a disservice.

In the words of Groucho Marx "I don't want to belong to any club that would have me as a member."

We could all choose be sour and jaded, fighting over scraps in a futile search for self-worth –OR– we could each take it upon ourselves to be the standard-bearers of what was, and hopefully will remain, a warm and inviting place for meritorious debate. I choose the latter.

Re: A Sad Day for Rust

#845

Post by finnthehuman » Fri, Jan 17, 2020, 10:22 PM UTC

dcolkitt wrote: post #566

ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

> 1. YOU are responsible for your dependencies. This is a nice idea, but in an era of one-button package managers it just doesn't work like that. You're trying to fight against New Jersey style. Which in the entire history of software has never been a winning approach. The reality is that for 95%+ of active software developers, done is better than perfect. Yes there may be a small subset of developers working on supe…

Very well stated. I'm jealous of your ability to articulate your point.

The underlying contradiction seems to be a theme in software development. People who haphazardly slap together inefficient and buggy software assume the safety-critical software I've worked on must be engineered to an impossibly high standard in formally-proven Ada. We don't use Ada or formal proofs, for the same reasons nobody else does. I can say we are a lot more careful than 99+% of other projects, but we still live in the same software ecosystem everyone else does. I can't audit every platform and library we use with a fine tooth comb. A few million dollars will buy you a lot of reviews and testing (internal/external/penetration testing), but it will never be the platonic ideal of well-written software.

And Debian is a funny example for you to bring up. It's hard to take the temperature of a crowd online, but the HN attitude towards Debian's slow-and-careful releases in any other type of thread is that they're old fogies that don't understand the needs of modern software. I don't think even Debian lives up to this thread's level of code scrutiny that everyone should be doing all the time.

Re: A Sad Day for Rust

#846

Post by pimeys » Fri, Jan 17, 2020, 10:23 PM UTC

timjver wrote: post #777

jasonlotito wrote: post #183

Earlier quoted context omitted.

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 fo…

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.

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.

Re: A Sad Day for Rust

#847

Post by kelnos » Fri, Jan 17, 2020, 10:25 PM UTC

AnonymousPlanet wrote: post #143

manish_gill wrote: post #26

Earlier quoted context omitted.

> No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. It's not like he was getting paid to work on this, was it? And people do have a life beyond open source. People could have forked and worked on the issues themselves, but that's asking too much. Why do the hard work when you can just write a comment/tweet blaming someone else, right? Your comment is precisely what…

> It's not like he was getting paid to work on this, was it? That is completely beside the point. Do the Debian maintainers that were responsible for famous security slipups regarding SSH keys got paid? No. Would the backlash if they had been unwilling to fix the issues been warranted? Absolutely. Once you are a part of people's infrastructure and these people rely on you to not be irresponsible, you can't afford to…

Everyone has different goals and different tolerances when they work on open source, whether as a maintainer or contributor.

So there are some Debian developers who are unpaid and slavishly dedicated to fixing security issues and apologizing if they screw up? Great, that increases my confidence in them (I'm a Debian user and happy with that).

But guess what? There are also open source developers who do their thing as a casual hobby and just throw things out there because they hope it might be useful. They don't want to spend 50% of the free time they allocate to the project dealing with support requests and bug reports.

And there's everything in between, and above and beyond. I think this is a mistake that so many people make: that all open source developers are exactly the same, have the same motivations, want the same level of involvement, and have the same responsibility. That's just flat-out false. Every project and maintainer is different, and yes, it can be difficult to judge what kind of support you'll get when looking into taking on a new dependency, but that's the price you have to pay when you get something for no monetary cost.

You have no right to tell anyone what to do or how to do it unless you are paying them for the privilege of doing so.

> Once you are a part of people's infrastructure and these people rely on you to not be irresponsible

Nonsense. Absent a contract and some sort of consideration changing hands, you are responsible for your dependencies, and no one else.

> You can resign gracefully and let other people take over.

No. If users are unhappy with maintainership, they can fork. It's often contentious and not all that fun, but the (unpaid!) maintainer has no obligation to run the project the way you want them to.

Re: A Sad Day for Rust

#848

Post by kelnos » Fri, Jan 17, 2020, 10:32 PM UTC

tolmasky wrote: post #807

ginko wrote: post #16

Earlier quoted context omitted.

I'm not sure which license was used by actix-web, but let me quote the last section of the MIT license as a reply: > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILIT…

OpenSSL's license (Apache v2), also has the "AS IS" clause. I guess we should just wholesale dump any concept of security since the very basic technique of protecting oneself from litigation on the possibility of something going wrong should instead now be interpreted to mean "this is a toy project with zero guarantees". There is a difference between "Hey, this is a silly side project so definitely use at your own ri…

> OpenSSL's license (Apache v2), also has the "AS IS" clause. I guess we should just wholesale dump any concept of security since the very basic technique of protecting oneself from litigation on the possibility of something going wrong should instead now be interpreted to mean "this is a toy project with zero guarantees".

Essentially: yes. If you want any guarantees beyond that, you have to pay for them, or trust that others have paid for them.

Absent that, you have to make your own judgment as to whether or not the maintainers will run the project in a way you feel comfortable with. If they do; great. If not, move on (or contribute, or fork it), because you have no right to tell them how to maintain their project.

Re: A Sad Day for Rust

#849

Post by steveklabnik » Fri, Jan 17, 2020, 10:41 PM UTC

godshatter wrote: post #821

steveklabnik wrote: post #116

Earlier quoted context omitted.

I actually agree with you in a general sense, but our own opinions don't really matter much. What matters is the opinions in the aggregate. I wish that it wasn't perceived as such, but the reality is that it is. Ignore that at your own peril.

Why? What's the danger here? Is the original maintainer going to send someone named Vinny to break your legs if you fork a project that won't accept a security patch you need? I think you should just fork it privately, apply your patch, and move on with your life.

If you're keeping it private, none of this applies. I'm talking about "hey that project is bad, I am now maintaining a competing project, please use it instead."

Re: A Sad Day for Rust

#850

Post by svick » Fri, Jan 17, 2020, 10:41 PM UTC

tssva wrote: post #325

steveklabnik wrote: post #139

Earlier quoted context omitted.

Here is an example of an actual comment. I believe the thread is deleted now: > "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?" This is what I was thinking of when I wrote "far, far over the line."

Depending on the context that doesn't seem to be "far, far over the line." Just about any thread on HN regarding any aspect of systemd or Google will have comments which are much more vitriolic.

Just because something is common doesn't mean it's okay.