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

821–830 of 1001 posts

Re: A Sad Day for Rust

#821

Post by godshatter »

steveklabnik wrote: post #116
sequoia wrote: post #91

Earlier quoted context omitted.

> Forking is extremely aggressive This is not so. If you said "forking can be perceived as an aggressive action"* I would not disagree with you, but in the context of an FOS ecosystem, forking should not be perceived as aggressive, and it definitely is not inherently so. If someone doesn't want anyone to fork their project, why release it under an open source license? Free/Open source, full control: pick one. I objec…

I actually agree with you in a general sense, but our own opinions don't really matter much. What matters is the opinions in the aggregate. I wish that it wasn't perceived as such, but the reality is that it is. Ignore that at your own peril.

Why? What's the danger here? Is the original maintainer going to send someone named Vinny to break your legs if you fork a project that won't accept a security patch you need?

I think you should just fork it privately, apply your patch, and move on with your life.

Re: A Sad Day for Rust

#822

Post by kelnos »

bachmeier wrote: post #762
_-___________-_ 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…

> There's no need to flame people for running their open-source project the way they want to run it. You can just not use the code. It works both ways. You put something out there, you need to be ready for the response. I'm not a Rust user, but presumably there was a reason other than charity that he put it out there (show off his brilliance, use it to get jobs, I don't know - but it was something he did for his own…

I don't think "entitlement" means what you think it means. Unless you're arguing that people shouldn't feel entitled to be free of harassment, in which case I don't agree with you.

Yes, if you put something out there, you should expect feedback, and assume that some of that feedback is not going to be very nice. But that doesn't excuse the people giving that feedback for being rude. It doesn't excuse the fact that those people giving feedback have no inherent right to see that feedback acted upon, and expecting that is unreasonable and entitled.

I'm not saying I would have acted the same way the actix developer did (in my experience as an open source maintainer I certainly have some moments I'm proud of, and others that I wish I could take back), but I'm not so quick to condemn them, either.

Re: A Sad Day for Rust

#823

Post by kelnos »

jimbokun wrote: post #96
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…

Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: https://medium.com/@shnatsel/smoke-testing-rust-http-clients... Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article. Here is the first one I clicked on: https://github.com/algesten/ureq/issues/24 The maintainer is happy to get the report, and has an exchange w…

Here's the thing, though: you're looking at a very limited set of interactions (namely, n=1), and declaring that the developer of ureq is awesome and polite, and that the developer of actix is an asshole.

You don't know the history of either project, or either person. The developer of ureq probably has some bad days and responds in ways that their not proud of. The developer of actix has probably had some (many?) good days and responded politely and helpfully.

Indicting the actix developer given a small set of responses to a particular class of issues is a bit unfair.

Re: A Sad Day for Rust

#824

Post by p1esk »

mumblemumble wrote: post #816
p1esk wrote: post #805

Earlier quoted context omitted.

as soon as I saw the large amount of unsafe code, I stopped considering it at all So in that case you wouldn’t use any software written in plain C, right?

At the risk of projection, that comment reads to me as an attempt at playing gotcha. It's not necessarily that unsafe code is categorically bad and nobody should ever use software that is written without strong static guarantees. It's that, in a language like Rust that has such a high level of compile-time checking, and whose community places such a high premium on it, relying heavily on unsafe becomes a red flag. It…

relying heavily on unsafe becomes a red flag. It implies that the author of the code has a tendency to play fast and loose

It does not imply that. It might mean that the author knows what he's doing. Or not. We don't know without auditing the code.

defeat the ostensible purpose of choosing a language like Rust in the first place

The OP didn't try to choose a language - they tried to choose a piece of software that solves their problem. Seemed like the software was rejected on wrong grounds.

Re: A Sad Day for Rust

#825

Post by kelnos »

tunesmith wrote: post #770
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…

If you make your project public, does it by definition mean you are open to other people using your release? I think there's a difference between "Hey, use this project of mine," and "If you use this project, you're on your own..." I think a lot of these debates come down to this confusion. Some people assume the former (and expect some level of response), some the latter (and say it's as simple as forking if you hav…

It's really hard, though, because you'll always get people who will feel entitled. In the distant past I've released things and explicitly put in the readme something like "This is provided in the hope that it will be useful; I do not have time to support it and will not accept requests for help, but will consider merging patches that fix bugs or add useful functionality".

And yet I still got people who would ask for help with it, or file bugs without patches and then get angry when I wouldn't help them.

Re: A Sad Day for Rust

#826

Post by nindalf »

iforgotpassword wrote: post #799
nindalf wrote: post #729

Earlier quoted context omitted.

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.

Well they didn't find any specific issues. Just the overall code looked not up to their standards as well as how the maintainer dealt with feedback. What do you suggest one does in such a case? Every time I stumble upon shitty open source code, am I supposed to fix it and if the maintainer refuses the patches, patrol the internet and try to prevent anyone from using it?

> they didn't find any specific issues

The linked article specifically mentions that a specific soundness issue had been found and a fix had been submitted as well. If they had done nothing, it would have attracted no comment. If they had allowed another maintainer to review and merge, it would have attracted no comment. But they went out of their way to denigrate the people who called attention to this issue, called the issue "boring", rejected the patch, then deleted the issue and all comments.

> Every time I stumble upon shitty open source code, am I supposed to fix it?

Your tone suggests that you don't want any part of this, so you continue along that path. I'm not going to convince you to start caring about your fellow men and women.

Re: A Sad Day for Rust

#827

Post by mfo4321 »

carapace wrote: post #555
fnord77 wrote: post #445

Earlier quoted context omitted.

> It was never Nikolay's job to vet actix-web for you Imagine if the linux maintainers took this attitude. This attitude severely undermines the credibility of opensource. If users of opensource libraries can't have confidence that those libraries are written correctly, we might as well all go back to commercial software.

What would be the basis for confidence that those commercial libraries are written correctly since you can't audit the source code?

Judging by the feel of the thread, 'professionalism', defined here to be money exchanged. No need to audit the code, just sort by price and take the highest bid!

Re: A Sad Day for Rust

#828

Post by sneak »

disintegore wrote: post #265
jasonlotito wrote: post #165

Earlier quoted context omitted.

From the grand parent: "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." The reply: "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ... FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT." Furthermore, from the GP: "No one expects you to wri…

I didn't think it could be so difficult to separate legal contracts from social ones. If you have voluntarily assumed the role of maintaining an open source project, it's perfectly reasonable for people to expect you to address merge requests and issues on the issue tracker. It's reasonable to expect a maintainer to process technical arguments and justify their technical decisions. The maintainer of course has no leg…

Legal statements aren't special. They are also plain old social statements, which I think was his point. It's not solely a "don't sue me".

Re: A Sad Day for Rust

#829

Post by nindalf »

kelnos wrote: post #820
nindalf wrote: post #729

Earlier quoted context omitted.

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.

Yes, and you're making the same mistake that you're railing against: if you're going to invoke some sort of moral imperative to do something, you have to examine the risk of what can happen if you do nothing. In the case of something like Heartbleed, yes, the consequences of silence could be quite high. But I just can't see the same argument against remaining silent for this web framework. It's also a matter of degre…

There were specific issues found in this library. Soundness holes as a result of unsafe. And people submitted fixes. This person could literally have done nothing and it would have been ok. But they went out of their way to be terrible to everyone.

Re: A Sad Day for Rust

#830

Post by sneak »

Ragnarork wrote: post #95
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…

What must have gone horribly wrong during the course of software history that led to people acting so entitled about free open source projects? You use it, you evaluate then accept the consequences. You don't? Well Patch it. You can't? Use an alternative. Nothing else available? Fork it and fix it. If nothing works for you, then either you're the problem, or the entire field has an unsolved problem (and you're not he…

This is an oversimplified view. One could say the same thing about eg free services from Google or Facebook.

It doesn't prevent us from saying "operating in this way is bad/destructive", even if one chooses not to use the code or service.

Post reply on HN