A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#221

Post by unethical_ban » Fri, Jan 17, 2020, 4:14 PM UTC

deng wrote: post #155

cforrester wrote: post #129

Earlier quoted context omitted.

That doesn't mean it's wrong to criticize his choices, so long as it's done without being insulting.

Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.

You know, there is a lot of "He isn't required" but I will say there are reasonable expectations that people have when a project gets to a certain level of exposure/downloads/etc. and while someone should not be "cancelled" or tarred and feathered for not accepting a merge request, if your project is a leader in its niche (Rust web frameworks) you should do better.

You publish your code to Github, you're part of a community. You make it open and allow for contributions and see people are using it, you should be clear about your level of give-a-shit.

Re: A Sad Day for Rust

#222

Post by notyourday » Fri, Jan 17, 2020, 4:14 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.

Based on the noise the "maintainer shall/should/must/ought to" crowd is gigantic. It should not be an issue for this group to fork whatever they are kvetching about and do whatever "shall/should/must/ought to". So fork it and implement it!

Re: A Sad Day for Rust

#223

Post by thrower123 » Fri, Jan 17, 2020, 4:14 PM UTC

spamizbad wrote: post #25

Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.

It is so much less work to whine and complain and poke holes in other people's work than it is to roll up your own sleeves and dive into the shit yourself.

Re: A Sad Day for Rust

#224

Post by throwlaplace » Fri, Jan 17, 2020, 4:14 PM UTC

wgerard wrote: post #177

throwlaplace wrote: post #163

Earlier quoted context omitted.

no your argument isn't useful. the question is never about rights because we all know what the maintainer's rights are (so it's always a discussion of obligation). if you accept that the open source projects are voluntary as an axiom then you in fact cannot criticize choices made by the volunteer. here's an analogy: a homeless person asks for money. you don't give him money but buy him food. can the homeless person r…

Here's another analogy: A homeless person asks for money. You don't give him money but give him some advice. Can the homeless person rightfully criticize you? You can absolutely criticize choices made by volunteers. I don't think you need to think too deeply about this to imagine situations where few would object to criticizing a volunteer's behavior. An obvious one would be if an open source maintainer willfully inc…

what is the relationship of your analogy to this situation? is the maintainer the homeless person in your analogy?

you can criticize all you want as an exercise of your critical thinking faculties but the volunteer is not in anyway obligated to heed the criticism.

"it's my money/time and I'll spend it how I want, which includes burning it"

is the fundamental axiom. Given that that is the foundation what sense would it make to criticize that person for burning the money - it's right there in the premise that they're allowed to!

Re: A Sad Day for Rust

#225

Post by clarry » Fri, Jan 17, 2020, 4:15 PM UTC

einpoklum wrote: post #167

dpc_pw wrote: post #146

To start: any personal attacks against the author are unacceptable. Anyone is free to write whatever the code in Rust they like, and it is wrong to attack them about it. But .... I think it is showing that the premise of memory safety in Rust is working. Stuff that would go unnoticed in C and C++, is being identified and called out in Rust. Does it lead to drama, personal conflicts, etc.? Maybe. But from the perspect…

> Anyone is free to write whatever the code in Rust they like Let's take an extreme example: I write some program for common use and intentionally introduce a security hole or make it participate in bot-nets. And don't tell anyone about it. Am I "free to write it because I like it"? Well, in some sense, maybe, but it would also be something extremely problematic for me to do. Certainly everyone would scream bloody mu…

I think if you're actively deploying malware that people will run, the case is pretty clear. And when you say "for common use", it sound like you know that it is or intend it to be distributed and run by many people.

What's less clear is security holes (which are not malware as such) or just "putting code out there" ("not in common use", although someone could come and pick it up and start using it). I would defend your right to write exploits and backdoors and bots and put them on github.

Simply making a security hole is IMHO OK unless you have intent to exploit it (or let someone who intends to exploit it know about it).

The difference, for me, is in writing versus deploying. And I'd consider it deploying if you intentionally post malware to a public repo you know people will run (without knowledge of having malware in it).

Contrast with building a trap (and maybe showing it to people) and stashing it in shed, versus building a trap and priming it and putting it in the woods where you know kids like to play. Not a watertight analogy, I guess making traps could be illegal just like making guns is in many countries. But you get the idea. I think you should be allowed to write malware or make combat knives or mantraps for fun but don't put them to their respective use.

Of course, going down this line of reasoning is a rabbit hole. If you build something on your yard (something that isn't illegal per se and has no intention to harm anyone) and it turns out to be dangerous and someone gets hurt, you might have to take responsibility (but it really depends on a lot of factors and would be decided on a case by case basis). I'm not sure I would like such reasoning to be applied to FLOSS projects that come with a warranty disclaimer and which can freely be audited by anyone who intends to use them for real. It's not like they hurt you just because you happened to stumble upon them.

Re: A Sad Day for Rust

#226

Post by [deleted] » Fri, Jan 17, 2020, 4:15 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…

[deleted]

Re: A Sad Day for Rust

#227

Post by samatman » Fri, Jan 17, 2020, 4:15 PM UTC

stanferder wrote: post #80

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…

It might not be just reddit though. The author's summary points to a volatile combination of elements in Rust itself: 1) [T]he Rust project saw Rust as more than just the language... 2) unsafe... is a really important part of Rust, but also a very dangerous one, hence the name. If a project is considered to be not just a project, but something closer to a cause, people are going to defend their understanding of that…

Rust didn’t introduce this language, they adopted it. Memory safety has been called that as long as I’ve been programming.

Using the antonym of safe was a natural move, though with the benefit of hindsight, `danger` would have been a better keyword.

After all, good unsafe code isn’t unsafe! It is dangerous though, because it forgoes guarantees of memory and resource safety provided by the compiler.

Re: A Sad Day for Rust

#228

Post by megaman821 » Fri, Jan 17, 2020, 4:15 PM UTC

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…

Is there anything else you would like to demand about people's code they you are not paying them to write?

I demand you go write a tool that lets me query projects and tells me if you think they are a toy or not. I'll wait.

Re: A Sad Day for Rust

#229

Post by tssva » Fri, Jan 17, 2020, 4:16 PM UTC

deng wrote: post #155

cforrester wrote: post #129

Earlier quoted context omitted.

That doesn't mean it's wrong to criticize his choices, so long as it's done without being insulting.

Of course you can criticize, but people are continuously demanding things, like "he should have labeled it as a toy project", "he should have given reasons why he didn't accept the patch", etc. And Drew is very right to say: No, he didn't have to do any of that.

You are right that he didn't have to do any of the things people pointed out but that doesn't mean choosing not to do them isn't fair game for criticism and "he should have labeled it as a toy project" and "he should have given reasons why he didn't accept the patch" seem more like fair criticisms than making demands.

Re: A Sad Day for Rust

#230

Post by zozbot234 » Fri, Jan 17, 2020, 4:16 PM UTC

withoutboats wrote: post #89

This situation is the sad and absurd result of two processes going on in the Rust community. The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of…

Didn't the Rust stdlib just gain a high-performance hash map recently? Is there a real case for using a custom implementation in reqwest? I could see Shnatsel getting a bit frustrated wrt. that choice.