Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

131–140 of 1001 posts

Re: A Sad Day for Rust

#131

Earlier quoted context omitted.

Ah, point taken. But perhaps it’s better in situations like this where the original maintainer feels harangued by the community?

Forking someone’s project because they won’t accept your PRs will definitely make them feel harangued by the community. I’m not sure if it necessarily has to be that way, but creating a hostile fork is conventionally considered very rude.

This should change though. That's the correct course of action if a maintainer won't mainline what you want them to. Or is absent altogether.

Re: A Sad Day for Rust

#132

Earlier quoted context omitted.

Sure, so in the case of actix-web, the decision of many has been to stop using the project because it wasn't safe. I didn't see any discussion of legal liability, just a community deciding to stop using and supporting this library. (Just going by Klabnik's article, I knew nothing about this library before reading it. There may be more context of which I'm not aware.)

I am not aware of anyone bringing legal liability into this situation, in any form.

I am replying to a comment citing legal liability language from a license?

Re: A Sad Day for Rust

#133
Help me out here is actix-web some sort of software that is integral to Rust?

If not ... I get the idea he wasn't really welcoming of the changes but at the same time. It's his code man.

I came from the world of networking and etc and the world of programming has a great deal of personal preferences / hypothetical problems / "we don't do that at my workplace" stuff pushed under the guise of technically correct ... sort of technical bullying.

Under that sometimes there's little room for mistakes / other points of view, other working styles, and etc... and it's really horrible.

Re: A Sad Day for Rust

#134
I think there are three things that combine to cause the underlying problem:

1. Open source creators own the package and they owe you nothing. Most (all?) of the major package repositories follow this model.

2. There are very few ways to officially fix a major dependency if the creator(s) take a powder beyond cajoling or forking and attempting to maintain it yourself.

3. Many people are using VERY complex and important packages that, frankly, they may not actually be able to maintain themselves. I fall into this category for some packages that I use and I'm sure most people do, especially on small projects.

So, you are left with hoping the OS creator stays on top of things or cajoling.

Once cajoling fails, and you are in a bind, a bind that may threaten your job and career; things get ugly. It's not right, but it's human nature and it's predictable.

I'm identifying the problem, I really don't have a solution.

Re: A Sad Day for Rust

#135

The Rust community is very, very toxic. They fight internally, but externally, they take over any thread about anything and make it about Rust.

Was here to post something along this line. The only place in which I'm (hopefully) in contact with the Rust community is here. What do I see all the time?

- "rewrite it in Rust" kind of posts on a lot of threads

- upvoting Rust mildly or not interesting projects just because there are written in Rust

- down voting every comment that even slightly criticize Rust (this comment will be gray when you'll read it) or remind that code safety exists in VM language for decades

Re: A Sad Day for Rust

#136

Earlier quoted context omitted.

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

Its not just you.

Re: A Sad Day for Rust

#137

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 how my own attitude shifts in favor of cooperation when I must couple my face with my words. And I wonder if others feel the same.

Re: A Sad Day for Rust

#138

Tried reading through this but without context it’s very unclear what has happened. Can someone familiar with Rust and it’s communities explain from a high level what all this is about?

The Rust community is filled with Don Quixotes who treat maintainers of popular open source packages like they are dimwitted sidekicks.

Re: A Sad Day for Rust

#139

Earlier quoted context omitted.

This is why I wrote "forked". They do have the right to not accept PRs for their own project, no? Sure, someone can be a bad steward, or maybe just opinionated. Doesn't give anyone the right to be mean to the point of making them quit their own project.

All of this is second hand, where are the mean comments "making" this person quit their own project? Were they actual personal attacks, or just criticism of the code? If you can't accept legitimate criticism of your work, that shows a real lack of maturity. (The article didn't give concrete examples, so I don't know which is the case here.)

Here is an example of an actual comment. I believe the thread is deleted now:

> "seriously? Please just stop writing Rust. You do not respect semver, you do not respect soundness, so why are you using a language predominantly based around doing these things right?"

This is what I was thinking of when I wrote "far, far over the line."

Re: A Sad Day for Rust

#140

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.

> Forking is extremely aggressive,

Is it really, though? It is more of an "agree to disagree" situation.

Just like the maintainer doesn't owe you anything, you don't owe the maintainer blind loyalty, either.

Post reply on HN