Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

621–630 of 1001 posts

Re: A Sad Day for Rust

#621

I am disgusted by the cultural phenomenon of making sarcastic call-out comments on twitter/etc., with an eye towards building up enough community outrage to force an issue. There are people who forget that open-source does not entitle you to anything (read the fucking license). Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without so…

> read the fucking license

> It sickens me

> I am disgusted

Almost sounds like you're... outraged? Perhaps trying to build up community outrage?

Re: A Sad Day for Rust

#622

Earlier quoted context omitted.

> It was never Nikolay's job to vet actix-web for you Imagine if the linux maintainers took this attitude. This attitude severely undermines the credibility of opensource. If users of opensource libraries can't have confidence that those libraries are written correctly, we might as well all go back to commercial software.

They do. It is right there, in the LICENSE file. It is a simple cost/benefit analysis. Your risk of presuming that Linux today is sufficiently good for what you need to do is lower than it was 10 years ago, which is why Linux today is more popular than 10 years ago and a lot more popular than it was 20 years ago.

Following this logic, if a popular rust crate doesn't prioritize security, it can potentially change people's risk assessment of the rust ecosystem as a whole. So this maintainer's actions could have negative effects on other rust projects with no relation to his. He may not have an obligation to do anything about it, but it's kind of "not cool".

Re: A Sad Day for Rust

#623
post #343
post #302

Earlier quoted context omitted.

> 1. YOU are responsible for your dependencies. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, 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. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

if a maintainer is a jerk to their contributors, that is of course their right, but...they are being childish.

Re: A Sad Day for Rust

#624
post #613

Earlier quoted context omitted.

Agreed 100%. May I add one point? The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project: how much are they open to change the project's core values, how responsive on average will they be in terms of opened issues and PRs, roughly how often would they engage in technical architectural debates -- stuff along those lines. I feel many people get toxic if they had unrealistic e…

> The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project Why do you think they owe you this? You didn't pay them, and they didn't accept a contract.

I don't feel I am owed this at all. I feel only that it's being a good open-source citizen.

When you make something that people use and like and want to improve, you should at least have the common decency to tell them beforehand: "this is my show, not gonna accept PRs".

I don't think it's such an exhausting job to write two lines at the top of the README.

Re: A Sad Day for Rust

#625

Earlier quoted context omitted.

Okay, I massaged the GitHub API logs[0] with jq to make a readable version of the issue history[1]. I was firstly (based on the blog post) feeling bad about the maintainer... but after reading the issue report, it turns out multiple people were working on the issue and the author responded... 'this patch is boring'. That's... certainly not good to people who are trying to resolve the issue. He even goes to threatenin…

Thank you very much. Are there some deleted comments that might have been missed? If not the conversation was civil until the maintainer refused a patch for a "boring" reason.

As I mentioned in the post, this situation has been going on for a long time. You'd need to read a few dozen pages to get the full context here.

Re: A Sad Day for Rust

#626

Earlier quoted context omitted.

All of this is second hand, where are the mean comments "making" this person quit their own project? Were they actual personal attacks, or just criticism of the code? If you can't accept legitimate criticism of your work, that shows a real lack of maturity. (The article didn't give concrete examples, so I don't know which is the case here.)

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

I think it's a cultural issue, but I honestly don't see what's so offensive about this comment (I was expecting something far worse), especially if it's factual assumptions are true. Honest question, can somebody explain the issue here to me, and how one would express these concerns otherwise? I feel as if I just don't get American culture of politeness and niceness to appreciate it.

Re: A Sad Day for Rust

#627
post #302

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. They not only created issues, they also created patches. That is taking responsibility. They were contributing time and expertise back. Having a project maintainer then call those patches boring or otherwise disregard them? That's childish. He showed time and time again he would respond without civility when an issue was demonstrated in his code. Sadly, that led to some…

> they had likely invested considerable time at least using, if not more.

I think your choice of the verb "invest" implies a highly flawed mindset about the incentive structure of open source.

A lot of open source consumers have a mindset that by using someone's open source project you're giving them something or doing them some kind of favor. "Hey, I'm investing in your project!" You aren't.

From a maintainer's perspective, simply using a project is likely either a zero or net negative. You are not investing your time, you are using their code. You may be asking questions which consume their time. You may be filing bugs which are on code paths they personally don't hit and fixing those uses up their time. For open source projects that pay for hosting things like their repo and issue tracker, you're consuming network resources.

We have a finite time on Earth, and supporting users is time the maintainer cannot spend with their friends and family, relaxing on a beach, taking a stroll, etc.

A consumer of an open source project may cancel out that drain by offering other things in return: popularity, kind words, the feeling that the maintainer has created something that benefits other humans. Filing issues can help a maintainer fix bugs and feel good about the improved quality of their code. Pull requests can add functionality they want.

But none of that is a given and often does not happen.

In my open source projects, I have certainly receive kind words, but also many angry words in bug reports. I've had demands to spend huge amounts of time making sweeping changes, pull requests that needed be basically be rewritten, the feeling that I'm letting people down by not replying to issues quickly enough, etc.

I believe the right mental model is that if you use someone's open source project, you are in their debt by default. They have used their labor to create an artifact that provides clear material value to you. They did work. You got personal value. They clearly owe you absolutely nothing and you reasonably owe them something approaching the material value you get from their code.

This doesn't mean you need to pay them, but it should inform how you interact with them. Filing issues and sending pull requests may pay off that debt, but even then it is not a given that every issue and PR is a net help to them. Maintaining an open source project can be gratifying, but it can also be hugely draining. It would be less so if consumers were more sensitive to that fact.

Re: A Sad Day for Rust

#628
post #331

Earlier quoted context omitted.

Depends on how you define web. IOT should be done in low level languages. but yeah I agree that a REST server is better of in something like GO, C#, or JAVA.

IOT is generally less of a target. I'm more talking about http endpoints to be consumed by browsers anywhere in the world. That makes the whole world your adversary.

> IOT is generally less of a target.

Lol. That's the thing about IOT - the 'S' is for security, right?

Re: A Sad Day for Rust

#630

A few years back I started using Rust after spending many years working with Go full-time and the first thing I noticed was that the team really focused on only providing the language, that libraries like HTTP were being pushed out to the community to contribute. It's a totally fair position for a language to take, but I found it disappointing coming from Go where I knew I could just use 'net/http' and move on to sol…

The language team has been focusing on providing the primitives needed for an efficient HTTP client and server, that is, async/await. That only got stabilized a few weeks ago. If we had put HTTP in the standard library before then, it would have only been synchronous. That would have been a huge drawback.
Post reply on HN