Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

41–50 of 1001 posts

Re: A Sad Day for Rust

#41
The larger pity, to me, seems to be the maintainer's decision to not only quit the project, but to take down the repo with the intent to delete it:

https://github.com/actix/actix-web

I get it, they feel personally harassed and slighted. And it's their project, they can do with it what they like. But it still feels like the decision is motivated more by spite than by a desire to simply wash one's hand of the project. Surely there are not hostile developers who would've been willing to take over the maintainer role.

Re: A Sad Day for Rust

#42
What makes me sad is that someone spent a huge amount of time making something, working on something, supporting something. If you don't like that something, then use something else or write your own thing. I don't get how there is some responsibility of maintainers to turn a passion project into anything other than what they want?! Fork.

Re: A Sad Day for Rust

#43
post #4

It brings up the question — as a developer, how can you best set boundaries on your customers so that you can have some degree of control over the toxicity of the culture that you're exposed to when interacting with them?

It's a good question. I'm involved in a large open source project that attracts some of this kind of attention. Because of the project's age, much of our infrastructure is old, which actually sort-of works to our advantage here. If you want to be a jerk to us, you need to go find our mailing lists and figure out how to send an email, or register a Bugzilla account and go file some troll bug. Much more effort than posting "You Suck" on GitHub or whatever. The barriers are insulating, which has pros and cons.

The other part that works well for me is disassociating your self from your project. Set strict hours for when you will work on the project, and don't work on it outside of them. Note that checking issue emails counts as work; remove your "work" email from your phone. I'm lucky enough to be a paid developer for the project, so I can clearly define my working hours as when I'm in the office, and ignore issues when I'm not at the office. But even for personal projects, there's no need to respond to issues within hours, or even days, if doing so is burning you out.

And the obvious answer that applies to anyone who creates anything online: Don't Read The Comments. In this case, that means Reddit. Reddit is a cesspool of uninformed users giving maximum visibility to whatever is most appealing to other uninformed users; not a good place to get useful feedback. Find spaces that are supportive and provide useful feedback, cultivate them, and spend your time there.

Re: A Sad Day for Rust

#44
I agree with what another person has said on github- the rust community on reddit is incredibly toxic. The last time such a thing happened, there were losers who made personal attacks on Nikolay. Then Nikolay showed up in comments being angry that he had helped that particular loser only a few days back.

Its easy to create blog posts and comments about RIIR, its not easy to actually write code.

If anybody actually wants to fix this issue and prevent it from happening again, I'd start by instantly banning /r/rust users for 3 days anytime they do a circlejerk.

Re: A Sad Day for Rust

#45
post #16
post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

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…

We're not expecting a warranty and we're not asking for damages.

It's not really surprising that the Rust community is made out of people who've chosen to take extra effort in security, and that they wouldn't tolerate a cavalier attitude to it. It's disappointing that this was expressed in an unconstructive way.

Re: A Sad Day for Rust

#46
post #32

Previously, in the Ruby community: https://blog.steveklabnik.com/posts/2011-08-19-matz-is-nice-...

That situation is a little different for a number of reasons, but the broad strokes are the same.

Sam tweeted at me recently about this situation: https://twitter.com/sstephenson/status/1167856878673694728

Re: A Sad Day for Rust

#47
I dont know what people expected from him, he was working 12 hour days already. If they didn't like it then they could just try to help him out instead of tearing down the work he was doing. Did he not accept PR's because he didn't have time to get to them all? Either way, writing an article further isolating him for all his work isn't going to make the situation better.

Re: A Sad Day for Rust

#49
post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

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

[deleted]

Re: A Sad Day for Rust

#50
post #6

I don't know how to word this so I'll say it bluntly (and probably bear the blunt of this community as a consequence): If you're a developer of a project that is used in a security-sensitive context, you either be receptive to security concerns or you clearly label your project as a toy project. No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Of course, you could…

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

From what sklabnik's post says, patches were submitted but the author wasn't really receptive to them.
Post reply on HN