A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#511

Post by rumanator » Fri, Jan 17, 2020, 5:53 PM UTC

bpfrh wrote: post #124

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…

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.

> The problem was that PRs which would have fixed security issues where not accpeted.

It actually was not. The article is quite clear that the problem was created by the way the Rust community, particularly the one at Reddit, acted and reacted so poorly with regards to the way a project was maintained.

Let this be as clear as possible: the problem is not nor it ever was any PR. The problem is the appalling way the Rust community attacked the maintainers of a project.

Re: A Sad Day for Rust

#512

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

People are not robots, but in terms of reaching agreement between humans, "emotion" is more or less just a difference in priorities, which is one of the ways reasonable people can disagree.

If we agree on the facts and we agree on their implications, but we still disagree, it's likely because we weight things differently. Emotions are simply a large component for how we weight things.

Re: A Sad Day for Rust

#513

Post by downerending » Fri, Jan 17, 2020, 5:55 PM UTC

olah_1 wrote: 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 noticed a whiff of this early on and just moved on. I deal with enough politics at work. At play, I want to do fun tech and that alone.

Re: A Sad Day for Rust

#514

Post by Youden » Fri, Jan 17, 2020, 5:55 PM UTC

endothrowho333 wrote: post #21

> “Why Reddit is like this” is a whole other essay; I think it’s built into reddit’s structure itself. Classic Eternal September. Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new u…

A forum being large doesn't have to lead to a loss of cultural identity.

My favourite counter-example is /r/AskHistorians. Over a million members (16x larger than 60k) and it has some of the highest quality posting and discussion I've seen anywhere on the internet. I think it serves as a prime example of how a well a forum can scale, if done properly, so long as there are strict rules and moderators.

Re: A Sad Day for Rust

#515

Post by dependenttypes » Fri, Jan 17, 2020, 5:56 PM UTC

hjek wrote: post #407

Ygg2 wrote: post #342

Earlier quoted context omitted.

> They were hateful and virtrolous Who's they? Most of PR commenters were courteous. The last few were rude, but so was the fafhrd91. https://gist.github.com/mafrasi2/debed733781db4aba2a52620b67...

> 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 was posted after fafhrd91 was rude. Also...

> The last few were rude, but so was the fafhrd91

Re: A Sad Day for Rust

#516

Post by fragmede » Fri, Jan 17, 2020, 5:56 PM UTC

notyourday wrote: post #437

derefr wrote: post #303

Earlier quoted context omitted.

Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure. Adding to this, you might still transitively depend on the upstream through your other deps in ways you can’t change without either forking a…

The level of entitlement here is absolutely insane. If the community cares about security then should this happen: > Sure, but once you’ve forked, now you have a fork only you use, but which you know is more secure than its upstream for reason X. That’s an unstable equilibrium—you want others to know of your fork, and to switch to it, so that other downstream projects can also be more secure. The community would move…

Following Dave Rand's framework, the conversation went something like:

"Atrix-web should not use unsafe"

"Thank you for volunteering - you are now in charge of making atrix-web not using unsafe"

"Thank you for delegating responsibility of making atrix-web not use unsafe, to me. I accept responsibility for this piece, but you are still the leader of $PROJECT." "Here is a PR that makes atrix-web less unsafe."

"I don't accept your PR."

Dave Rand's advice doesn't apply here, as several people picked up responsibility for making atrix-web less unsafe, put forth the work to do so, but were rejected. It's one thing for me as a user to feel entitled to everyone else doing what I think they should, while not putting in any effort, but IMO it's less clear cut when I'm putting my money when my mouth is, and submitting PRs.

Re: A Sad Day for Rust

#517

Post by Macha » Fri, Jan 17, 2020, 5:56 PM UTC

skywhopper wrote: post #448

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…

I've worked with Rust only rarely, and never built anything real from scratch with it myself, so I'm curious: what tools are available to assess the safety of dependencies? I agree with you in principle that "you are responsible for your dependencies", but how would you go about doing that for a large complex dependency like this?

cargo-geiger will recursively warn you of unsafe code in dependencies: https://github.com/anderejd/cargo-geiger

It's not a silver bullet, it will show you areas where memory safety issues could arise, but doesn't necessarily prove the presence of memory safety issues. Memory safety issues aren't the only type of security bug so them being impossible also doesn't mean it's entirely safe. You can think of issues like injection attacks or faulty ACL logic happening without memory unsafety.

There's also cargo-crev, which is an attempt at making a web of trust for reviews of third party packages: https://github.com/crev-dev/cargo-crev - for a longer form article on what crev's goals are and how it works, I found this explained it for me: https://wiki.alopex.li/ActuallyUsingCrev

Re: A Sad Day for Rust

#518

Post by Animats » Fri, Jan 17, 2020, 5:56 PM UTC

I have been complaining about Rust's "unsafe" for years. There's too much "unsafe" code because there are things that you either can't express, or are very hard to express, in safe Rust. I've pointed out partially initialized arrays and backlinks as key trouble spots. Both are potentially fixable. I've gotten back complicated excuses for not dealing with these design problems. There was a serious denial problem in the Rust community. Now it's come back to bite them.

Language design that forces users to lie to the language leads to this. The classic is C's "a pointer is also an array" mindset. When you write

   int read(int fd, char* buf, size_t buflen)

that "char *" is a lie. You're not sending a pointer to a single character. You're sending a reference to an array of unknown size. That design mistake in C has probably been the cause of more serious bugs than any other mistake in the history of programming. If you have to lie to the language, the language is broken.

Rust had so much promise, too.

Re: A Sad Day for Rust

#519

Post by gwd » Fri, Jan 17, 2020, 5:56 PM UTC

vvillena wrote: post #363

mlthoughts2018 wrote: post #198

Earlier quoted context omitted.

> “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anyth…

People have a right to become angry. They absolutely don't have any right to override the will of a project maintainer. By the way, isn't this a great opportunity? The code is open. Fork it. Seize the day. Become a better maintainer, and build a community around your fork. Ensure the community needs and wants are aligned with yours. Steer that ship. Gain prestige. And money, maybe. If someone is a bad maintainer, the…

> People have a right to become angry.

No. You have a right to be annoyed, and then fork the project if you want.

You do not have a right to become angry unless you're paying for it.

Re: A Sad Day for Rust

#520

Post by fapjacks » Fri, Jan 17, 2020, 5:56 PM UTC

_wzsf wrote: post #335

fapjacks wrote: post #214

Man... Wouldn't it be great if this same attitude often seen in users of open source software was had by regular people toward civil liberties? Like where people just pile hate on the codifiers day in and day out, because they are owed their entitlements by birthright.

That's kinda how politics works. Sorry to have to tell you :(

You didn't understand what I wrote. To put it into simpler terms: Over time, people demand less and less about their civil liberties, whereas with open source projects, people demand more and more.