A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#451

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

I’d argue that if a company has a larger than normal dependency on keeping a project running (like a cloud provider with 1 million VMs running Debian or Debian-based OSes) they should hire a full time employee whose sole job is to work on it.

I think the basic rules still apply: You’re getting this software for free rather than paying for something expensive. Though you deal in the software, you get no guarantee of its fitness for any purpose. If you want a better guarantee of its fitness, either pay the current maintainers or hire someone good who can become a maintainer. OR choose open source projects where a BigCo like Microsoft or Google has hired people to work on it full time.

Re: A Sad Day for Rust

#452

Post by tssva » Fri, Jan 17, 2020, 5:28 PM UTC

pgeorgi wrote: post #270

tssva wrote: post #229

Earlier quoted context omitted.

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.

> "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. Those are demands. The toy project one is relatively low cost, but "he should have given reasons" brings with its lots of effort to do right - and then you get to do it over and over again, because the masses can fling shit at you faster than you can reas…

demand: an insistent and peremptory request, made as if by right.

critcism: the expression of disapproval of someone or something based on perceived faults or mistakes.

"he should have ..." is clearly an expression of disapproval.

Re: A Sad Day for Rust

#453

Post by TiccyRobby » Fri, Jan 17, 2020, 5:29 PM UTC

The article mostly consider both side and the main point is to flourish open source community, which is highly appreciable.

I think, as an outsider, both side had its wrongs and corrects, the author could consider changing unsafe code and the community could be at least civil.

As a personal opinion, i can say that we have to consider the fact that the authors of open source software are mostly doing it for hobby or fun. And if we ever want to keep open source alive and magnificent, we should be very civil and and at least thankful for the programmer and their time.

The only way out i see that could solve the issue was to fork the project and do the desired changes there. I dont know why they did not do that when it got to that point.

Re: A Sad Day for Rust

#454

Post by ivanbakel » Fri, Jan 17, 2020, 5:29 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?

Cherry-picking a comment doesn't give a good representation of the community. The GP is right - most comments were courteous. The point is that saying "the community" was hateful and vitriolic needs more evidence than a couple of bad eggs, because those exist everywhere.

Re: A Sad Day for Rust

#455

Post by virtue3 » Fri, Jan 17, 2020, 5:29 PM UTC

eropple wrote: post #380

jakear wrote: post #357

Earlier quoted context omitted.

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.

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

It's a bit disingenuous that you can accuse someone of being absurd for not doing something, and then mentioning in the same breath that you "might not want to" as well.

I'm merely saying that for the sake of pointing out that maintaining a project is a PITA and we should all really accept that.

Re: A Sad Day for Rust

#456

Post by jasondclinton » Fri, Jan 17, 2020, 5:29 PM UTC

ddevault wrote: post #83

dashwav wrote: post #73

Earlier quoted context omitted.

> 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 anything in the slightest. I don't think the anger is directed at there being security issues, the anger is directed at the fact that even when security vulnerabilities where found and patched, there was major pushback even getting those patches merged into the library.…

>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care" Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in ma…

You're lumping a few bad apples (apparently recruited from Reddit) in with "they". The users who found the bugs and provided patches were largely courteous considering the circumstances.

Re: A Sad Day for Rust

#457

Post by barbarbar » Fri, Jan 17, 2020, 5:30 PM UTC

I have no knowledge of actix-web. But just starred at the insane high throughput achieved in the world most thorough benchmark test. Just horrible to read about what the author had to go through. But fully understand him.

Re: A Sad Day for Rust

#458

Post by floatingatoll » Fri, Jan 17, 2020, 5:31 PM UTC

braythwayt wrote: post #274

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…

My viewpoint is as follows: 1. Just because a thing exists, does not give you the absolute moral right to criticize it, especially in a way that is toxic for the person or persons that created it. Criticism affects both the people criticized and the community/universe at large, and not always in positive, productive ways. 2. Just because a thing is free, does not grant the thing or its creator absolute immunity from…

#1 is imprecise to me in one respect.

Critiquing someone's actions and choices is a founding principle of open source software, politics, and in general most human culture. "I think it was wrong to delete the GitHub issue because my belief structure XYZ" is acceptable.

Critiquing someone personally based on their technical choices is not acceptable. Reddit allows it, and thus Reddit is unusable as a social platform for positive outcomes. "I think you are a bad person because you deleted a GitHub issue" is NOT OKAY.

That distinction appears to be what led the creator to quit today, because the GitHub issue they deleted (perhaps incorrectly) contained personal attacks that linked their technical choices to their quality of human self (definitely incorrectly). I personally would have chosen to XYZ and I think they'll do so in the future if that comes up in a GitHub issue again — but focusing on that is incorrect here.

The focus needs to be on those who wield personal attacks on others over technical choices, and on rewriting communities to prohibit and evict these participants in all cases where such can be done. Shun them, ban them, and prohibit them.

Re: A Sad Day for Rust

#459

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

munmaek wrote: post #430

_-___________-_ wrote: post #352

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

What do you use now? Warp?

[deleted]

Re: A Sad Day for Rust

#460

Post by dbcfd » Fri, Jan 17, 2020, 5:31 PM UTC

munmaek wrote: post #430

_-___________-_ wrote: post #352

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

What do you use now? Warp?

Right now, if you want async/await, you either have warp or tide.

Hopefully gotham or rocket gets around to updating.