A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#591

Post by the_af » Fri, Jan 17, 2020, 6:30 PM UTC

jakear wrote: post #357

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…

Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibili…

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s.

Out of curiosity, isn't a focus on that kind of things precisely the goal of Rust? I understand your point, but this was software built for Rust, which has this kind of thing (safety, the right types, etc) as a primary goal.

From https://www.rust-lang.org/:

> "A language empowering everyone to build reliable and efficient software."

and

> "Why Rust? Reliability: Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — and enable you to eliminate many classes of bugs at compile-time."

So I can understand why someone bypassing this kind of things and then (for whatever, possibly understandable reasons) rejecting PRs to patch them because they are "boring" can be perceived as seriously mismatched with Rust's community. If someone finds this kind of thing "boring", is Rust really for them?

Note: I'm not saying he has any obligation to do anything. I'm just saying his attitude may seem mismatched with the community and goals of his chosen language, which is no small problem.

Re: A Sad Day for Rust

#592

Post by [deleted] » Fri, Jan 17, 2020, 6:31 PM UTC

cle wrote: post #435

steveklabnik wrote: post #350

Earlier quoted context omitted.

Yeah, and interestingly, a lot of unsafe functions use "unchecked" in their names. The issue was that by the time this was recognized, there was too much Rust code, and there was no clear alternative that people universally liked. This kind of conversation is the definition of bikeshedding. I submitted an RFC and it... didn't go well. (I think I picked "trustme" though.)

I don't think it's bikeshedding. It does seem to be contributing to the dogmatism I'm seeing from the Rust community here, and this community reaction is a huge problem for Rust. So it matters.

[deleted]

Re: A Sad Day for Rust

#593

Post by blueprint » Fri, Jan 17, 2020, 6:32 PM UTC

solipsism wrote: post #306

elefantastisch wrote: post #189

Earlier quoted context omitted.

Meta-comment: Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based. Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.) Much of what makes…

This is a bit Pollyanna. People aren't logic robots that start from first principles and then derive all knowledge from logical reasoning. People are emotional, irrational beings. Those of us who fancy ourselves rational are constantly involved in irrational motivated reasoning helping us maintain that desired worldview. Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But the…

What if it's actually only those who are honest who have human nature?

Re: A Sad Day for Rust

#594

Post by xscott » Fri, Jan 17, 2020, 6:32 PM UTC

TheRealDunkirk wrote: post #186

lallysingh wrote: post #111

Earlier quoted context omitted.

Why is the maintainer responsible for that? They're just another dev who wrote something that became popular. It's almost like watching lottery winners having their lives ruined.

> Why is the maintainer responsible for that? It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like t…

> You get help on the project in the form of people contributing patches, right?

It seems like you're trying to make it seem like there is always a legitimate exchange, and so they owe you something. Some projects want help, others don't. In the latter case, it's just a gift from the author, and they don't owe you anything.

Re: A Sad Day for Rust

#595

Post by kllrnohj » Fri, Jan 17, 2020, 6:33 PM UTC

Touche wrote: post #551

kllrnohj wrote: post #503

Earlier quoted context omitted.

> 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. It is when they setup an open source project that has that appearance and is framed as being such a project. It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant…

Read the license, it frames the project exactly.

The license only frames the projects legal responsibilities. It is entirely unrelated in every way to how the project is run on a day to day basis.

Alternatively if we're going to just go strictly by the license then the maintainer deserved all the flames & flak he got. After all, it wasn't against the license, therefore he cannot complain about it. Just like that idea is unreasonable, so too is trying to hide behind the license in this case.

Re: A Sad Day for Rust

#596

Post by compiler-guy » Fri, Jan 17, 2020, 6:35 PM UTC

mratsim wrote: post #563

compiler-guy wrote: post #376

Earlier quoted context omitted.

"The maintainer owes the community something, simply because the community decided to adopt the project." Doesn't work that way, I'm afraid. The maintainer already gave the community something, and doesn't owe them anything more.

They owe people who write PR basic courtesy, not refusing patches on ground that it is "boring".

"Basic courtesy" is one thing. Accepting patches because they don't find them interesting is another thing, is different, and not required.

Giving someone the mere ability to make a PR is already a gift far beyond what the original author owes.

Re: A Sad Day for Rust

#597

Post by saityi » Fri, Jan 17, 2020, 6:36 PM UTC

weiming wrote: post #356

The "unsafe" keyword should probably just be called "unchecked," otherwise it is a bit of a misnomer.

I think 'unchecked' would be a bit of a misnomer; code inside of unsafe blocks is still checked by the compiler for many things. The borrow checker is even on IIRC.

Re: A Sad Day for Rust

#598

Post by sergiotapia » Fri, Jan 17, 2020, 6:37 PM UTC

First the “rust being a moral programming language” and now this - I’ve never seen a community stain a language so poorly as the rust people. Wow! And I was there when Zed Shaw Cale’s rails a ghetto.

Re: A Sad Day for Rust

#599

Post by mratsim » Fri, Jan 17, 2020, 6:37 PM UTC

pcr910303 wrote: post #391

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…

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.

Re: A Sad Day for Rust

#600

Post by Alex3917 » Fri, Jan 17, 2020, 6:37 PM UTC

ddevault wrote: post #38

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…

> Open source participants are volunteers and owe you nothing.

Of course they do. It’s not legal for you to distribute software that puts others in harm’s way. You’re not allowed to give poisoned food to homeless people as long as it’s free.