A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#391

Post by pcr910303 » Fri, Jan 17, 2020, 5:07 PM UTC

manish_gill wrote: post #26

vunie wrote: 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…

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 threatening to delete the organization if people talk about the issue.

[0] https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a5...

[1] https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...

Re: A Sad Day for Rust

#392

Post by rckoepke » Fri, Jan 17, 2020, 5:07 PM UTC

BowBun wrote: post #343

dbcfd wrote: 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…

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

I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illegal or anything. They can choose to be irresponsible, yes. But personally, I think that maintaining the repo is the maintainer's responsibility. And I think the responsible way to do that involves "following best-practices, responding to feedback/PRs, or responding in any coherent way to anything asked of them."

I'm NOT saying a maintainer should have to add features to satiate the masses. I'm merely saying that a "maintainer" has some small duty to "maintain" a product, and also acknowledging that they have a legal right to abdicate that responsibility.

I'm not sure anyone should be immune from social criticism. They can always make someone else the maintainer and avoid any future work/limelight/criticism.

I won't touch the childish vs. adult debate as it pertains to abdicating one's responsibilities.

I am also NOT saying that people should "expect to be be served high-quality open-source software for free, and then outrage when it isn't." But it seems like it's a maintainer's responsibility to allow (and maybe even facilitate) competent, motivated individuals to contribute to their open-source project.

I also don't know exactly what the reddit brigading involved, this is the first time I've heard of this story. Harassment obviously is not okay and, not coincidentally, is illegal.

Re: A Sad Day for Rust

#393

Post by harikb » Fri, Jan 17, 2020, 5:07 PM UTC

One thing that isn't considered is that these "benchmarks" are a rat race to the bottom in code quality. You can't blame the author(s) from wanting to win this fictitious wall of fame. I don't know why exact numbers like "6.9987 million/sec" exist. There should be a saner way to run benchmarks, which in turn creates sanity among developers.

This viewpoint is, of course, unrelated to the community discussion here. I mean other languages have unsafe (or c's void *), but they don't appear to fight about it. I don't mean to say anything bad about Rust. But it seems to attract people who want the absolute best performance at any cost. IMHO. May be I am wrong. That may be something Rust people can try to change??

Re: A Sad Day for Rust

#394

Post by pcr910303 » Fri, Jan 17, 2020, 5:07 PM UTC

jsjohnst wrote: post #55

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…

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.

Yeah, that is the case.

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 threatening to delete the organization if people talk about the issue.

[0] https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a5...

[1] https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f...

Re: A Sad Day for Rust

#395

Post by gatherhunterer » Fri, Jan 17, 2020, 5:08 PM UTC

People being people. I disagree with both the author’s code choices and his treatment. I imagine most feel the same. Rust will be fine. The lessons learned about choosing dependencies wisely and taking responsibility for those choices will be scarce.

Running software is always more of a performance than an institution.

Re: A Sad Day for Rust

#396

Post by pgeorgi » Fri, Jan 17, 2020, 5:09 PM UTC

NopeNotToday wrote: post #245

IMO, the most telling point of this is when the author rejected a security patch because it was not creative enough. He was more of an artist than an engineer. What was the patch? It was very strait forward, simple, uncreative change, intention was just to remove unsafe not to fix existing code. I believe software development is one of the most creative work we do, and creativity is part of why we love software devel…

> He was more of an artist than an engineer.

Assuming this is true: What's the problem with that?

Re: A Sad Day for Rust

#397

Post by UncleMeat » Fri, Jan 17, 2020, 5:09 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…

Some floss developers choose to work for free. That’s fine or even admirable.

That doesn’t mean that everybody needs to. If a dev isn’t being paid then they should have the absolute right to refuse all maintenance or even just destroy the project.

I’d keep my code closed source if there was a risk that it would start getting used and suddenly I’ve got an extra job for zero pay.

Re: A Sad Day for Rust

#398

Post by cogman10 » Fri, Jan 17, 2020, 5:09 PM UTC

vvillena wrote: post #339

bpfrh wrote: post #124

Earlier quoted context omitted.

The article was not about that, this is not about vetting anything. The problem was that PRs which would have fixed security issues where not accpeted. Do I expected perfect code from maintainers or a answer the next day? No, never Do I think maintainers/creators should merge prs in a timely manner, or ask for help if it get's too much? Yes, otherwise you have multiple forks and the project is not usable anymore.

If this is the issue, one of those forks will become the new mainline repo everyone contributes to. Expecting a maintainer to behave the way the community wants is unreasonable. Maintainers are not public servants. I mean, anyone can fork it and become a maintainer, and create new guidelines and inclusive rules that ensure the project is steered in the "right" direction. Isn't it the case? I understand the "we just w…

> If this is the issue, one of those forks will become the new mainline repo everyone contributes to.

I know that is how it is "supposed to work". However, I've very rarely seen it actually work that way.

The problem is the "first-mover advantage" and it is a hard one to overcome. If you make a "maintained actix-web" fork, most people will still find their way to the dead project. Even worse, many resources and tutorials will point to the old library. A search for "actix" will almost certainly give confusing and frustrating results to the novice.

Re: A Sad Day for Rust

#399

Post by rakasaurus » Fri, Jan 17, 2020, 5:09 PM UTC

krn wrote: post #305

disintegore wrote: post #202

Earlier quoted context omitted.

If I understand correctly, your anecdotal evidence is what makes this not "armchair psychology"?

What's wrong with simply sharing personal observations based on the decades of related personal experience? Anyone who has some training in science has learned to always be looking for patterns.

Theres nothing wrong with it. Calling someone an armchair psychologist is an anti social behavior.

Re: A Sad Day for Rust

#400

Post by zpallin » Fri, Jan 17, 2020, 5:09 PM UTC

nradov wrote: post #271

zpallin wrote: post #137

Earlier quoted context omitted.

Agreed. I think there is quite a lot of entitlement on the internet and as Klabnik pointed out: on reddit. And while it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability, fundamental disagreement should result in forks, not vitriol. It's moments like this that I reflect on the past and the public and virtual forums I have participated in... and…

Open source maintainers have no such responsibility. Anything you get for free is a gift, and giving a gift doesn't create any ongoing responsibility for the giver. Take it or leave it.

I disagree here, but only within the confines of the language I used. A maintainer of open source code is willingly submitting their own work to be used for free by others. They have no responsibility to extend it at all, but to maintain it is to do so in the interest of the users... they have a responsibility to do it to the best of their ability, and if not, the maintenance should be given to someone who will.