Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

51–60 of 1001 posts

Re: A Sad Day for Rust

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

A similar disclaimer is contained in the GPLv2 and therefore applies to the Linux kernel. Does that mean we can not impose any expectations regarding security on its maintainers either?

Why can't we have legal disclaimers like this so that the legal system with its tech-oblivious case law and multi-million-dollar penalties is prevented from interfering while also retaining softer sanctions such as the threat of community ostracism/obnoxious messages to incentivise some degree of quality?

Re: A Sad Day for Rust

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

Sure, so in the case of actix-web, the decision of many has been to stop using the project because it wasn't safe. I didn't see any discussion of legal liability, just a community deciding to stop using and supporting this library. (Just going by Klabnik's article, I knew nothing about this library before reading it. There may be more context of which I'm not aware.)

I am not aware of anyone bringing legal liability into this situation, in any form.

Re: A Sad Day for Rust

#53
post #11

I actually think the "code of conduct" culture that Rust embodies exacerbates this kind of drama. Ironically, it creates a more unsafe environment where everyone feels anxious and judged by the CoC Police. Under the CoC, I am entitled to a wonderful experience, and if I don't get it, the culture has failed in its commitment to me.

I have literally never felt "judged by the CoC police" in any project that has one. I have no idea why you would ever feel that way. Pretty much every CoC says "do not be a raging asshole". I am fully capable of not being a raging asshole, and if I slip up and am, I would be happy to be told off for it.

Re: A Sad Day for Rust

#54
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 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?

Personally, I don't think you really can. I think the best thing to do from a developer/maintainer perspective is to identify toxic communities and do you're best to ignore them entirely. That's probably the best long-term approach from a mental health standpoint.

Especially when it comes to social media sites like Reddit, once a community turns hostile there really isn't anything you can do to turn it around.

Re: A Sad Day for Rust

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

I don’t have the full picture here, but the source article implies that folks weren’t just complaining, but also offering PRs to fix the issues, which were rejected. That feels less like entitlement to me and more like bad stewardship of the project, but again, most of my info is biased by source article.

Re: A Sad Day for Rust

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

More like you should be expected, as a user, to look at the code youre using and determine if it fits your set of criteria. If you dont think its updated enough, or the authors free labor isnt fast enough for your needs, then dont use it. You come off super entitled and arent the only one. This is the kinda stuff thats making me start my new projects closed source instead of open by default.

Re: A Sad Day for Rust

#57
This is a sad day for Rust. Situations can spiral out of control. Who started it? Who escalated it? You can't really define these because communication is sloppy and difficult, especially when there are cultural and language barriers involved. The only way to not get these situations to spiral out of control are a thick skin, forgiveness, and assuming noble intent.

There have been times on here where I see discussions around `unsafe` as if it was a curse. I think the discussions, over time, have gotten more nuanced which helps.

I also wonder if expectations were unclear. It now sounds like the focus of Actix was on performance and creativity / cleverness and not on being a mature product. I never heard that before. Maybe even the author didn't even originally articulate it so clearly but discovered it through these discussions.

Going forward, I hope someone archives their clones of actix and that people fork that and get it moving forward as a product. I hope people don't take a religious view of removing `unsafe` during the fork but instead follow best practices (benchmark to confirm the need, abstract it to test it, offer a feature flag for the paranoid to disable as much of it as possible).

Re: A Sad Day for Rust

#58
I think the Rust compiler should write as its final log message "Resulting binary contains x bytes of unsafe code" (or something similar). That way, people are constantly reminded that their code depends on unsafe code, and they can try to reduce that with visible results.

Re: A Sad Day for Rust

#59
post #33

Tried reading through this but without context it’s very unclear what has happened. Can someone familiar with Rust and it’s communities explain from a high level what all this is about?

The really short answer seems to be: actix was a Rust web framework. It did some things internally that some people didn't like. The Internet echo chamber picked that up and amplified it to a volume the maintainer couldn't justify working through. The Internet echo chamber is now going to pick this up and amplify it to a volume that probably isn't justified either. I think this is another story about the destructive…

Good explanation. One could argue that you see this playing out in Politics and News Media.

Re: A Sad Day for Rust

#60

Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.

Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

Ah, point taken. But perhaps it’s better in situations like this where the original maintainer feels harangued by the community?
Post reply on HN