Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

681–690 of 1001 posts

Re: A Sad Day for Rust

#681

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…

Part of using any piece of software, professionally or privately, open source or commercial, is assessing how well if will meet your needs now and in the future, and possible complications you might anticipate.

Doing this well and thoroughly is extremely hard, and commercial enterprises spend a lot of time and money doing so (or pay the equivalent of insurance to not worry about it). Doing a minimal amount of research entails doing what you did. Look at the current and past state of the item in question, and decide whether it's worth putting the significant amount of time and effort into using it.

I can't help but feel the vast majority of people complaining failed to do this minimal amount of legwork. They're upset about their lack of forethought for what they view as a bad investment, but that's on them. Unfortunately, I find people often have a hard time accepting blame onto themselves, but feel there is blame to be assigned, and so it needs to be directed somewhere.

They say don't look a gift horse in the mouth, but if you are responsible for dealing with whatever diseases that horse might introduce to your stable, or even if you are just legally obligated to deal with the care and feeding or removal on death of such a large animal, you definitely look that horse in the mouth for red flags.

Re: A Sad Day for Rust

#682

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

[deleted]

Re: A Sad Day for Rust

#683

Earlier quoted context omitted.

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

> Open source is not some backyard game anymore. It > involves companies and their commitment in form of > infrastructure and participation. I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too. What I'm readin…

> I think this approach leads to sustainability problems, and discourages individuals from sharing their work in open source form. I make a project because I need it, and maybe it's fun to build. I generally share it because I think others might find it useful too.

I don't believe that every little open source project is automatically held to the rules I described. But once your exposure gets bigger, you suddenly enter different waters. Hopefully you might have maintainers of a distribution shielding you from the biggest impact.

> What I'm reading in your comment is that once it becomes widely used, it becomes my responsibility to meet the needs of these people and organizations who have started using the work I freely give to them. The act of having it used by other people obligates me to them.

That is precisely what is happening in many places. I didn't say I like it. In most cases people can move. Sometimes the "market" moves on or forks it. But this is what I have been seeing more and more.

> If the goal is only to build a thing and share it, there can be no such obligation - regardless of how popular it gets.

This is tricky. Viewed from the moral standpoint of the starter of the project, I agree. But once you got into the limelight with your project and other people started depending on it, every misstep suddenly becomes a jackass move. You essentially lost the project.

Re: A Sad Day for Rust

#684

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. I can't agree. Not for all participants. Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would…

I partially agree. I _do_ actually think that you have a certain obligations to your users.

For Rust, my personal mantra was always that _usage is contribution_. Why? Because we have a high interest in adoption. It's literally one of our top-priority goals.

But not everyone taking part in these discussions is a user or someone I have some kind of relationship with. And a relationship goes both ways.

To take your example: if a kid showed up and was _constantly_ loud, didn't respect you or showed no interest in learning? What if _most_ of the kids were like this?

Would you still like to go every Saturday?

I do teach in similar settings (RailsGirls, RustBrige) and a crucial part of the experience for me is that many attendees have a progress that they are thankful for. The deal and the relationship works, even if it is just short.

My big frustration is that the debate is often "Maintainer vs. Users", but I don't believe that boundary is as hard as people make it to be. Still, user entitlement exists and is _very_ rampant and this is what people are up against, even if they put it less nuanced. (maintainer entitlement also exists, but that's a story for another day)

Re: A Sad Day for Rust

#685
post #660

Earlier quoted context omitted.

Linus is paid to carry that responsibility. Others are not.

True, but for the reasons I detailed above, it's not the payment that matters. Linus could also probably make more money on a different project, but he's committed to Linux.

> but there'd probably be a couple weeks of chaos. Does Linus bear zero responsibility because he's a volunteer

Linux Foundation would appoint somebody else on his place and have him sign similar contract. It would be likely a person that is already employed in similar capacity - one of current paid maintainers. No fork would be needed. Linus Torwalds is not a volunteer at this point.

Linus Torwalds will leave linux one day. He wont stay there forever - most likely to retire, but possibly to do something else.

Also, Linux is particularly bad example, because most contributors are paid for their effort by someone.

Re: A Sad Day for Rust

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

I wholly agree with your viewpoint in this comment.

There is a prominent "Fork" and "Clone" button in every GitHub repo. If you're so fucking sick of the lack of support from the maintainer, fork it, fix the flaws that you've found, and assume some of the responsibility for the project.

This whole situation is a bunch of people getting angry because of what they view as a lack of accountability. That's preposterous - the nature of GitHub and open source makes it super easy for you to assume some of that accountability yourself. The fact that so many people chose to get upset rather than assuming accountability speaks volumes to me.

Pull requests welcome, jerks.

Re: A Sad Day for Rust

#687

Earlier quoted context omitted.

Holding people legally responsible for bugs in their FOSS code would be a good way to ensure that no FOSS code got written. Ever.

I didn't mean legal responsibility here (perhaps the example was somewhat poorly chosen), but surely there's some level of responsibility here? Bugs happen, security issues happen, facts of life, but actively rejecting security patches is another level of irresponsibility.

> ...surely there's some level of responsibility here?

No, there isn't.

> ...actively rejecting security patches is another level of irresponsibility.

No, it's not, because the project owner has literally no responsibility to you or anyone else in the context of this project.

If you care, you need to fork and patch the project. If you're feeling generous, you can share that fork and maybe others will use it.

Re: A Sad Day for Rust

#688
post #343

Earlier quoted context omitted.

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

> 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. It is when they setup an open source project that has that appearance and is framed as being such a project. It is entirely the maintainer's responsibility to establish the type of open source project it is. If it was just a toy hobby project and that's all it was meant…

Your statement is false. They called for contributors many times, last time in August https://github.com/fafhrd91/actix-web/issues/1019 .. This was public and open message and is not the first time.

Though while people are ready to open issues and complain, sometimes even supply patches and make big noise if they do not pass code review, there were nobody who could join to share responsibility in making decisions about the project.

Re: A Sad Day for Rust

#689
post #354
post #100

Earlier quoted context omitted.

As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.

As a maintainer, I treat almost all PR submission with kind words. What actix developer did was, to pardon my French, inexcusable. Deeming security patch boring? Making your own `Cell`, implementing it badly and misusing it, because it's faster on some stupid benchmark site? If we designed cars like that, they would have no breaks, no gears and no cabin. Honestly, I think it's better Rust abandons `actix` asap. Befor…

The "boring" was in response to the comment above it, which was discussing if the patch is large enough to merit a statement that they are contributing under the projects license.

The patch was "boring", not substantial to claim copyright.

Re: A Sad Day for Rust

#690

Earlier quoted context omitted.

I thought basic etiquette was issue to discuss before PR? Starting with a PR seems to me like saying "you have nothing to tell me about how your code works, I know exactly how your code should be changed and if my changes conflict with what you're working on you should throw your code out because mine is better". Is that wrong?

I agree that should be the basic etiquette. Perhaps it needs to be said more clearly on project pages and codes of conduct and participation. (Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales. Luckily, if you don't get the response you wanted, you can fork a…

> Of course, it is not reasonable to demand that an already-overworked maintainer-for-free find extra hours to have the pre-PR discussion either. It needs to be exploratory and respect the maintainers' timescales

I absolutely didn't mean to imply that. I also think that a pre-PR discussion can be useful because if the maintainer doesn't have time to say they want a PR that's a decent hint they won't have time to handle the PR.

Post reply on HN