Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

Post reply on HN
Print view View original

461–470 of 1001 posts

Re: A Sad Day for Rust

#461

Post by dbcfd »

TiccyRobby wrote: post #453

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 f…

> I dont know why they did not do that when it got to that point.

I think most people kept hoping they weren't at that point, and could actually move forward without forking.

Re: A Sad Day for Rust

#462

Post by Attained »

This is something JavaScript does better than Rust. I like the JS community because it's way more sympathetic on average. They have lots of code quality issues to solve in some of the hardest ways... But people are working on that, and I think they will succeed eventually, if they haven't already fixed much with npm audit.

Re: A Sad Day for Rust

#463

Post by pdimitar »

BowBun wrote: post #343
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…

> Having a project maintainer then call those patches boring or otherwise disregard them? That's childish So what? Along the same lines, 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. The fact that you call them childish for not acting they way you want them to makes me think you are the childish one. With those PRs w…

You are correct in general. I'll just add the nuance that when an open-source project gets beyond a certain popularity and usage threshold I'd expect the project's governance to take a stance that's more responsive to PRs.

That doesn't include any money incentives and that is likely the problem here.

Maybe `actix-web`'s author should apply for GitHub sponsorship. Maybe small sums of money every month will motivate him to take PRs more seriously.

Re: A Sad Day for Rust

#464

Post by pgeorgi »

zpallin wrote: post #388
kd5bjo wrote: post #307

Earlier quoted context omitted.

Actualy, it’s the maintainer’s responsibility to make their code serve their own interests. Those often, but not always, align with the users’ interests.

Then why open source at all if there is not some interest in helping others who have "aligned interests"?

So that others can pick the pieces they need, if they care to. It's an offer to the world, not a sales pitch.

Re: A Sad Day for Rust

#465

Post by mynegation »

dbcfd wrote: post #302
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…

> 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…

You cannot change other people, you can only change how _you_ react to other people and the world around you.

If Actix is that important to so many people, eventually there will be a person and/or organization that will step up, fork the projects, apply the patches, set the principles and code of conduct (or not), keep as much "unsafe" code as they deem necessary and try to rally the community around it.

The open source creators and maintainers gave you something and asked for nothing. They are people with their weaknesses, faults, insecurities, and other passions and commitments, like we all are. Get the best of what they are willing to give, give them the best you are willing to give and they are willing to accept, and move on.

Re: A Sad Day for Rust

#466

Post by HorstG »

cogman10 wrote: post #398
vvillena wrote: post #339

Earlier quoted context omitted.

If this is the issue, one of those forks will become the new mainline repo everyone contributes to. Expecting a maintainer to behave the way the community wants is unreasonable. Maintainers are not public servants. I mean, anyone can fork it and become a maintainer, and create new guidelines and inclusive rules that ensure the project is steered in the "right" direction. Isn't it the case? I understand the "we just w…

> If this is the issue, one of those forks will become the new mainline repo everyone contributes to. I know that is how it is "supposed to work". However, I've very rarely seen it actually work that way. The problem is the "first-mover advantage" and it is a hard one to overcome. If you make a "maintained actix-web" fork, most people will still find their way to the dead project. Even worse, many resources and tutor…

Just as you shouldn't eat everything you just picked up from the sidewalk, you shouldn't just use any code thats available out there.

check, check and check again...

Re: A Sad Day for Rust

#467

Post by Skunkleton »

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…

> bear the blunt

It's "bear the brunt".

Re: A Sad Day for Rust

#468

Post by mottosso »

ckdarby wrote: post #441
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. Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something. Yes, I agree, volunteers don't owe anything but there are some unwritten rules that when broken should be frowned upon and I'd probably go as…

Here's another one.

1. Someone writes a library

2. Library becomes insanely popular

3. Users receive value out of library

4. One day, users stop receiving value from library

Is the author not responsible for the value generated by this library? At what point does the author become required to continue providing value?

"Just fork it" is an excellent response to (4), anything else is what entitlement looks like.

Re: A Sad Day for Rust

#470

Post by HorstG »

tolmasky wrote: post #362
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…

There’s an interesting gray area here: am I as a customer responsible for knowing the dependencies of a service I use? Most of the time that’s impossible. And things like GDPR seem to imply that people believe users are entitled to some degree to demand certain standards (privacy/security) from all web services. This is the potential problem with “just fork it”. If the library is used by a great many products, and yo…

GDPR binds an operator of a service. The developer can do as he likes.
Post reply on HN