Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

291–300 of 1001 posts

Re: A Sad Day for Rust

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

If you aren't satisfied with the code, fork it and fix it yourself. You are owed nothing. What right do people think they have to call someone out on it? Why do they feel entitled to other people's time and energy?

Re: A Sad Day for Rust

#292

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…

Seems like there should have been some sort of response from the maintainer about the _philosophy_ of why he was doing things the was he was, and people could either get onboard with the connecting points of that, or get lost. So far, in all of this drama, I have yet to see where any of that might have been explained. I don't use Rust, but I understand the significance of the experiment, and I think I for one, would…

There is absolutely no obligation to even reply to mails. Otherwise you fall into the trap of having to explain everything to everybody and not doing your project.

Re: A Sad Day for Rust

#293

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…

Seems like there should have been some sort of response from the maintainer about the _philosophy_ of why he was doing things the was he was, and people could either get onboard with the connecting points of that, or get lost. So far, in all of this drama, I have yet to see where any of that might have been explained. I don't use Rust, but I understand the significance of the experiment, and I think I for one, would…

While that might have made the community feel a little better, I don't think the maintainer had to do anything, certainly they don't have to explain why they made this or that decision.

People should decide if it's a big deal for them and if it is, fork the project to fix the issue or move to another library. I have had to do this many times myself, I kind of thought that's just how things worked with smaller projects. More than once I've found someone of a like mind has _already_ forked and made the change.

Re: A Sad Day for Rust

#294

This situation is the sad and absurd result of two processes going on in the Rust community. The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of…

Didn't the Rust stdlib just gain a high-performance hash map recently? Is there a real case for using a custom implementation in reqwest? I could see Shnatsel getting a bit frustrated wrt. that choice.

High performance relative to what? In the highest performance code, you will always want your own data structures, ones specialized for your particular use case. Generic facilities will never be quite as good. A general purpose language must support this kind of specialization.

Re: A Sad Day for Rust

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

"we do expect you to fix flaws when you learn about them."

If hope the plural we is also ready to monetarily compensate the developer for their time. Otherwise you don't have any basis for your expectation.

Re: A Sad Day for Rust

#296

Perhaps we can get at a deeper, more durable insight if we assume for a moment that most individual actors are well-intentioned, and that the described vitriol on one side and perceived stubbornness on the other is an externality of the unfortunate incentives (or lack thereof) that are parasitic on the open source community. It's almost instinctual/natural to misjudge the popularity of any project for some false sens…

It is a problem with people, people wanting to have their cake and eat it too. Open source is made of people.

Re: A Sad Day for Rust

#297

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…

Commitment can't be measured. It isn't a quantifiable thing, like dollars.

Re: A Sad Day for Rust

#298
post #273

Earlier quoted context omitted.

And this is why I honestly don't ever want to release an open-source project. At the very least, I'm not going to make it easy for people to contribute. I'll keep the git repo private, go without a ticketing system, and just post tarballs full of code on a self-hosted website (I guess like the NetHack team used to do before 3.6, but they had a ticketing system, and I wouldn't). Maybe I'll even use a non-free license…

Why? I mean, if you're that hostile to collaboration, why not just keep it closed source and maybe try to charge for it?

> Why? I mean, if you're that hostile to collaboration, why not just keep it closed source and maybe try to charge for it?

- There exist open source licenses (with copyleft) that disallow making it closed source.

- There exist other reasons to publish the source code: for example allowing the user to study it.

Re: A Sad Day for Rust

#299

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…

Agreed. I think there is quite a lot of entitlement on the internet and as Klabnik pointed out: on reddit. And while it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability, fundamental disagreement should result in forks, not vitriol. It's moments like this that I reflect on the past and the public and virtual forums I have participated in... and…

> it's definitely a maintainer's responsibility to make their code serve the interest of its users to the best of their ability

No it isn't, unless those users are paying.

Re: A Sad Day for Rust

#300
post #100
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.…

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.

It's also the choice of anyone else to criticize him for not accepting security patches.
Post reply on HN