A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#371

Post by shkkmo » Fri, Jan 17, 2020, 4:59 PM UTC

tssva wrote: post #280

cerebellum42 wrote: post #168

Earlier quoted context omitted.

In this case it meant people saying things like "you are bad and you should stop writing rust, forever" possibly with some more colorful words in there. Very hurtful things but at least not threats and actions...

If someone poorly implements something, potential causes harm in doing so, doesn't accept that they have done so poorly and express a desire to learn and improve in future endeavors, it isn't even necessarily incorrect to express that they may not want to pursue that particular field anymore. Of course it should be done tactfully which I doubt most of the comments on Reddit did. I see this same sentiment expressed fa…

In what way is it correct or even helpful? Even if done tactfully, I have a hard time seeing that being taken by anyone as anything other than a personal attack.

The correct response would be to organize the community to create a fork that is more focused on correctness and security than on performance.

Re: A Sad Day for Rust

#372

Post by quotemstr » Fri, Jan 17, 2020, 5:00 PM UTC

steveklabnik wrote: post #324

quotemstr wrote: post #249

Earlier quoted context omitted.

What peril? Why is everyone treating online outrage mobs as if they had any power or authority? Who cares if some unimportant anonymous commentator thinks a fork is aggressive?

If you are trying to get people to use your project, understanding how those people perceive your project is step 1.

Agreed. But how do we define "people"? Are your prospective users all hanging out on Reddit and Twitter? Or are these two communities, as I believe, vocal but unrepresentative slices of a much larger potential silent user base?

Re: A Sad Day for Rust

#373

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

weberc2 wrote: post #346

pgeorgi wrote: post #266

Earlier quoted context omitted.

> Sure, but that DOES NOT mean you're immune to criticism The problem wasn't the criticism, but the expectation that said criticism invokes a certain behavior of the maintainer. You can criticize open source maintenance by creating a fork in which you outline your vision (e.g. "much less use of 'unsafe' in the web package") - and deal with the burden of being a maintainer. Everything else is just trying to force peop…

FWIW, I don't have a dog in this fight. On the one hand, there is the maintainer who is within his rights to accept or reject patches as he wishes (although it's not great that he's allegedly falsely advertising his project as secure) and you have critics who are within their right to criticize (although it's not great that much criticism is vitriolic, etc). As TFA says, it's a sad affair all around. > The problem wa…

> Criticism isn't "force" or "attempted force". If you think criticism is rude, that's fine. Hypocritical, but fine.

No, the attempt to make somebody do what you want by brigading is what's attempting to exert force and what's rude.

Hiding that behind "I'm just criticizing" (you didn't, but it's a popular refrain in such "debates") is more than only rude, it's also cowardice.

> You can't rationally say the maintainer is within his rights for rejecting security patches and then argue that critics are wrong for criticizing these practices.

The author of the package didn't force their code onto the users.

The authors of the criticism forced their criticism on him by throwing it his way in the form of bug reports etc. even when it was clear that there's no interest in it.

Re: A Sad Day for Rust

#374

Post by throwlaplace » Fri, Jan 17, 2020, 5:01 PM UTC

weberc2 wrote: post #355

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…

I reject the axiom. No one is above criticism provided the criticism is rooted in fact (i.e., defamation is not criticism).

it's not about whether someone is above criticism - it's about whether criticism makes sense in the context of what's being proffered. in another part of this branch of the thread i make the analogy with a an artist's sketch posted to a public art gallery. it's not that you can't criticize, it's that it doesn't make sense to criticize because the artist isn't attempting to achieve anything.

maybe a better analogy is if i play a pickup game of basketball and i get labeled a bad player for not trying my hardest. it's not that the criticism is misplaced it's that it doesn't make sense at all - i wasn't trying to be a good player! i was trying to have fun.

Re: A Sad Day for Rust

#375

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

I completely agree. This is why, as a small company, we prefer languages that have large organizations backing their open source libraries - such as Java - and prefer not to touch things like Rust with a ten foot pole.

Re: A Sad Day for Rust

#376

Post by compiler-guy » Fri, Jan 17, 2020, 5:01 PM UTC

wbl wrote: post #141

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…

Do you think we get software like zlib and libjpeg and BLAS and linpack by people shrugging off working for the community and failing to fix bugs? Otherwise we get dozens of half broken forks all over the place. That's no fun for anyone. This wasn't a drive by beg. This was a patch solving real demonstrable problems and at minimum there should have been a transition plan due to basic decency.

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

Re: A Sad Day for Rust

#377

Post by arendtio » Fri, Jan 17, 2020, 5:02 PM UTC

I think the simple version is that too many people don't understand how Open-Source works and that they have no right to tell a maintainer what he has to do.

If you are unhappy with the direction an Open-Source project is going, you can do two things:

1. Tell, in a civilized manner!

2. Fork, if you are willing to spend the resources to maintain such a project yourself

If you are unable to formulate your critique in a neutral way, then keep it to yourself (aka STFU). If a maintainer decides he doesn't want to follow your suggestions, you should be nice and stop. After all, you still have option two.

And if you are unwilling to spend the resources to maintain a fork, how dare you to tell someone who invests his time and shares his results, what he has to do.

Re: A Sad Day for Rust

#378

Post by zelly » Fri, Jan 17, 2020, 5:03 PM UTC

School-Cotton wrote: post #310

zelly wrote: post #252

That's okay, Rust should never be used for web anyway. I don't like the idea of Rust, C, C++, or Assembly for directly web-facing services. Any non-GC language should be a non-starter. There are literally (uncountably?) infinite ways you can have memory errors in a native program. The consequences of any of these can be devastating because absolutely anyone can access your endpoint. Notice the asymmetry: One small, u…

The set of all computer programs is countable, so I don't think there can be uncountably many ways to have memory errors.

That seems right. Memory errored programs are a subset of all computer programs.

The possible runtime states of a program (expanding every branch/subroutine recursively over all threads) is uncomputable. (Otherwise we would have a solution to the halting problem and be able to correctly free memory at compile time.) I'm not sure if that's the same as being uncountably infinite. It's probably a different concept.

Re: A Sad Day for Rust

#379

Post by cle » Fri, Jan 17, 2020, 5:03 PM UTC

stanferder wrote: post #309

cle wrote: post #264

Earlier quoted context omitted.

> And introducing the language of "safe" and "unsafe" isn't just descriptive, it's a value judgment. It has connotations of recklessness at least, and explicit threat at worst. Is it really a value judgment? Coming from a formal PL background, I had just assumed that the "unsafe" keyword was referring to the PL concept of "safety", AKA "soundness", which has a specific technical definition, and not that it was necess…

Points well taken, but I think "unsafe" turns it into a value judgment, especially (as samatman says adjacent) since it isn't necessarily really unsafe.

It is unsafe. There are just multiple definitions of unsafe being used here. I agree that it's unfortunate that the meaning of the keyword is easy to misinterpret.

Given the background of the people who designed Rust, I don't think it's reasonable to just assume that the keyword "unsafe" has an implicit value judgment.

Re: A Sad Day for Rust

#380

Post by eropple » Fri, Jan 17, 2020, 5:04 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.

Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change.

Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.