Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

1–10 of 1001 posts

Re: A Sad Day for Rust

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

Re: A Sad Day for Rust

#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 do neither, but don't be surprised when people call you out on it.

Re: A Sad Day for Rust

#7

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?

You can take a look at the actix-web repo, which has been wiped. A message has been added:

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

Re: A Sad Day for Rust

#8
> It’s unfortunate that a well-known project had soundness issues. It’s unfortunate that the maintainer wasn’t receptive to fixing them. At the same time, I’ve been there: being a maintainer is tough. It’s also unfortunate that there’s this style of response, and kind, and volume. It is true that the situation was dangerous. But did it have to be handled this way? You have to understand a lot of nuance here to even know the main points of the story. One version of this story that will certainly be told is “The Rust community says they’re nice but they will harass you if you use unsafe wrong.” Is that what we want? I, for one, do not. If you’re a part of Rust, you gotta ask yourself: are you happy with this outcome? How did your actions (or lack thereof) contribute to it? Could you have done something better?

Re: A Sad Day for Rust

#9
I can see where Steve is coming from about the difficulties of maintainer-ship - I only have a few projects that I am actively maintaining and obviously nothing close to the scale of a popular library. But at the same time I really think almost all of the blame in this case rests solely with the reception (or lack thereof entirely) of PRs/issues that are intending to improve the quality of a library that many people have come to rely on.

Our entire ecosystem that we have built (for better or for worse) by using these libraries as the foundations for countless projects necessitates that when a community is willing to give their time to improve a library that you maintain, the minimum that is to be expected is that you treat sincere contributions respectfully and not dismiss them out of hand.

It's unfortunate that the maintainer has stepped down entirely instead of changing how they are interacting with the community, but purely from a security standpoint I would rather a slower (but more secure and receptive) library take it's place than have a very popular library maintained by someone who doesn't seem to care about the overall code quality of the library they are a steward of.

Re: A Sad Day for Rust

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

Label and present your project clearly, both explicitly and implicitly, so that nobody could reasonably get the wrong impression about what level of development and support can be expected.
Post reply on HN