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

741–750 of 1001 posts

Re: A Sad Day for Rust

#741

Post by bloodorange »

cthalupa wrote: post #727

I generally believe people should be polite. But when you open source a project, you are opening yourself up to criticism and critique of your work. You are opening yourself up to that in basically any form the internet wants to take it, and sometimes that really can be shitty. We have a very promising project making use of a language that has gained popularity largely based on marketing around memory safety, and the…

Exactly! Everyone should demand a full cash refund for all that they paid for the maintenance of that piece of software.

Re: A Sad Day for Rust

#742

Post by mtalantikite »

steveklabnik wrote: post #630
mtalantikite wrote: post #84

A few years back I started using Rust after spending many years working with Go full-time and the first thing I noticed was that the team really focused on only providing the language, that libraries like HTTP were being pushed out to the community to contribute. It's a totally fair position for a language to take, but I found it disappointing coming from Go where I knew I could just use 'net/http' and move on to sol…

The language team has been focusing on providing the primitives needed for an efficient HTTP client and server, that is, async/await. That only got stabilized a few weeks ago. If we had put HTTP in the standard library before then, it would have only been synchronous. That would have been a huge drawback.

Oh absolutely, you actually mentioned that to me a few years back when I was first looking at Rust, and that’s a totally reasonable place to have been in. It’s just unfortunate that so many people decided to depend on an external library/framework and then got upset like this. For me it meant Rust wasn’t a language I should use for web servers at that moment, which hopefully won’t be the case for too much longer. I will say that as a user it’d be great to see an officially maintained lib like ‘net/http’, even if it isn’t a part of the std lib itself.

Re: A Sad Day for Rust

#743

Post by rjbwork »

cthalupa wrote: post #727

I generally believe people should be polite. But when you open source a project, you are opening yourself up to criticism and critique of your work. You are opening yourself up to that in basically any form the internet wants to take it, and sometimes that really can be shitty. We have a very promising project making use of a language that has gained popularity largely based on marketing around memory safety, and the…

I disagree, actually. There are no expectations of anyone that releases their code under most licenses. You get to use it as is, and if you want to change it, you submit a patch. Totally up to them if they want to take it or not.

If the current maintainer isn't doing what you, or "the community" wants, you fork and make the changes you want to see, and maybe eventually work with a group of people.

Maintainers are under absolutely zero obligation to the people who choose to use the code, unless they've specified as such in the license or some other contract. It's the only thing that lets FOSS software be a thing in the first place.

Re: A Sad Day for Rust

#744

Post by nomadnomad »

Alex3917 wrote: post #600
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. Of course they do. It’s not legal for you to distribute software that puts others in harm’s way. You’re not allowed to give poisoned food to homeless people as long as it’s free.

Of course they don't. It is Free OSS. And you implying that the maintainer put someone's life in harms way is simply not true. And the LICENSE says - no warranty or guarantee whatsoever... Use at your one risk. And the homeless people analogy makes very little sense, excuse me for being blunt. You are comparing software developers who use FOSS to homeless people??? You are comparing someone's FOSS project on github to poisoned food??? Are you for real??

Re: A Sad Day for Rust

#745

Post by swayson »

nindalf wrote: post #729
swayson wrote: post #717

Earlier quoted context omitted.

That is a false equivalence, roller coasters have far more material risk given human lives are at stake.

If you had discovered Heartbleed, would you have kept that knowledge to yourself so that you could minimize the maintenance burden on the OpenSSL develoopers? Granted, no one died over Heartbleed but it caused lots of real people harm. We should start worrying about the well being of our fellow human beings long before their lives are at stake.

Agreed, we have a responsibility as a community to not cause harm and even take effort to prevent it. That is what I like about HN, it is a place where these things are discussed and as a collective, positive outcomes can manifest.

Re: A Sad Day for Rust

#746

Post by oaiey »

watwut wrote: post #685
Wowfunhappy wrote: post #667

Earlier quoted context omitted.

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…

It is a bad example but most major open source projects are in that regard. However, the community driven ecosystems (Rust, Go, JavaScript ..) have significant components in that particular unpaid maintainer situation. And that is a problem.

Re: A Sad Day for Rust

#747

Post by ljm »

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…

This is quite an unusual topic but I find myself in agreement. But that's mostly because I don't agree with the general expectation that everything has to be a 'community', that the maintainer now has stewardship over. And the community is almost impossible to please as it grows larger and makes greater demands.

At one point it would have been code that anyone was free to use, before it becomes distorted as some bizarre social endeavour, and then people who've never used the software find themselves part of this 'community' and start to weigh in to add social pressure.

Use the software or don't; if the patches are rejected, fork it and go that way. If the maintainer won't merge the patches, because he has his own vision, you are perfectly welcome to branch out and follow your own. Or just use something else.

Having a maintainer adhere to a set of standards that only start to apply once 'the community' get involved and take control, is super unfair to the maintainer.

Re: A Sad Day for Rust

#748

Post by cthalupa »

rjbwork wrote: post #743
cthalupa wrote: post #727

I generally believe people should be polite. But when you open source a project, you are opening yourself up to criticism and critique of your work. You are opening yourself up to that in basically any form the internet wants to take it, and sometimes that really can be shitty. We have a very promising project making use of a language that has gained popularity largely based on marketing around memory safety, and the…

I disagree, actually. There are no expectations of anyone that releases their code under most licenses. You get to use it as is, and if you want to change it, you submit a patch. Totally up to them if they want to take it or not. If the current maintainer isn't doing what you, or "the community" wants, you fork and make the changes you want to see, and maybe eventually work with a group of people. Maintainers are und…

I'm not arguing they are under any legal obligation, but holding people responsible for something doesn't have to be a legal thing.

I feel that any open source software that I have released I have a moral obligation to fix any security issues, or if I am unable to for some reason, clearly stating that they exist. It is irresponsible to leave your software available with a known security issue.

Re: A Sad Day for Rust

#749

Post by bloodorange »

unethical_ban wrote: post #221
deng wrote: post #155

Earlier quoted context omitted.

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

I urge you (or anyone else who feels similarly) to seek a full refund for what you paid for the maintenance of that piece of software.

Re: A Sad Day for Rust

#750

Post by cthalupa »

bloodorange wrote: post #741
cthalupa wrote: post #727

I generally believe people should be polite. But when you open source a project, you are opening yourself up to criticism and critique of your work. You are opening yourself up to that in basically any form the internet wants to take it, and sometimes that really can be shitty. We have a very promising project making use of a language that has gained popularity largely based on marketing around memory safety, and the…

Exactly! Everyone should demand a full cash refund for all that they paid for the maintenance of that piece of software.

This is a common snarky retort when any discussion happens with open source software, but it doesn't add anything to the discussion.

There is a cost to using software that goes beyond money exchanging hands. The maintainer has no legal obligation to do anything, but acting as if someone having an issue with software having security vulnerabilities is someone being entitled is a childish reduction of the interactions in play here, especially when people are taking the time to write code that resolves the issue.

Post reply on HN