Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

111–120 of 1001 posts

Re: A Sad Day for Rust

#111

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…

Why is the maintainer responsible for that? They're just another dev who wrote something that became popular.

It's almost like watching lottery winners having their lives ruined.

Re: A Sad Day for Rust

#112

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…

Exactly this. If it doesn't meet your standards, don't use it. Alternatively, go fork yourself.

>If it doesn't meet your standards, don't use it.

>Alternatively, go fork yourself.

I think this could be the new template for Open Source Author to include in their OS work description should they choose to.

Re: A Sad Day for Rust

#113
I used to have this mental model for my (few, meager) open source projects: "I'm making something really cool in my back yard. You can come help when I'm home."

Eventually it's mutated into, "I'm making something really cool in the local park. I'll be there on weekends!"

I had to bake in the perception of not "owning" my creation because yeah, at some point it needs to grow well beyond what I had the time/energy/capability for. I'm also very human, and very insecure about my competencies, and as the youngest of three brothers, am defensive by nature.

Now practically speaking, how do you accomplish that in the open source community? I wish I knew.

Re: A Sad Day for Rust

#114

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…

As someone who works for a dod contractor this whole situation sounds crazy. Just because something is available as a crate doesnt mean you are to assume it safe or appropriate for your use. The onus of verifying the dependencies should always be on the consumer.

Haha - also a dod contractor, and sometimes wonder whether I'm the insane one who can't handle the wild west behavior of HN people surrounding npm packages...

Re: A Sad Day for Rust

#115
post #50

Earlier quoted context omitted.

From what sklabnik's post says, patches were submitted but the author wasn't really receptive to them.

In that case, you clone and fork. If you're just trying to get your stuff working, your fork is private. If instead you're trying to enjoy publicity, you publicize your fork. In neither case is it necessary to annoy someone who has already done a lot of free work for you.

Reporting bugs is annoying?

I want people to point out bugs in my code, so both my code and me as a developer can improve.

Re: A Sad Day for Rust

#116
post #91

Earlier quoted context omitted.

Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

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

Re: A Sad Day for Rust

#117

Question: why didn’t the more safety-focused developers just fork the project? I feel like fork-o-phobia causes 90% of the incidents like this.

Forking is extremely aggressive, and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project.

> and just because someone has the time to write a patch doesn't mean they have the desire or time to run a project

But at the same time, why should the original author do it? No one is paying for his or hers time.

Re: A Sad Day for Rust

#118

Here's the reddit thread in question: https://www.reddit.com/r/rust/comments/epoloy/ive_smoketeste... I have no doubt it led to some github issue brigading, but it's not really that big of a deal. Ostracizing /r/rust in a mealy mouthed way probably won't make that community better...

Yeah, I agree. “It’s all reddit’s fault” is not helpful at all and simply wrong from reading that thread.

Re: A Sad Day for Rust

#119
If I was the maintainer and someone offered a patch that didn't alter the properties of my code, but improved it, I'd be more then glad to accept it.

Unnecessary drama because of inflated egos.

Re: A Sad Day for Rust

#120

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…

> It was never Nikolay's job to vet actix-web for you

Perhaps, but if he claimed that it _was_ vetted, then he took on some responsibility for it (which he probably should not have).

Also, the blog post article claims, that you are never supposed to use "unsafe" code without having vetted it. Honestly, I doubt that very much, but if it's true than that's some responsibility taken too.

Post reply on HN