A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#361

Post by NewsAware » Fri, Jan 17, 2020, 4:57 PM UTC

aprdm wrote: post #337

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…

Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep.

Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Readme.

Re: A Sad Day for Rust

#362

Post by tolmasky » Fri, Jan 17, 2020, 4:57 PM UTC

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…

There’s an interesting gray area here: am I as a customer responsible for knowing the dependencies of a service I use? Most of the time that’s impossible. And things like GDPR seem to imply that people believe users are entitled to some degree to demand certain standards (privacy/security) from all web services.

This is the potential problem with “just fork it”. If the library is used by a great many products, and you know of a security vulnerability, merely providing an alternative that fixes it could be argued is not sufficient, while fixing it in the root library will patch the vulnerability in every product that has it in the next update.

It seems we still haven’t figured out (and perhaps never will) the exact responsibilities between all the parties at play.

Re: A Sad Day for Rust

#363

Post by vvillena » Fri, Jan 17, 2020, 4:58 PM UTC

mlthoughts2018 wrote: post #198

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…

> “ 2. Open source participants are volunteers and owe you nothing.” Absolutely not. They are compensated with prestige, enjoyment, decision-making power, future employment rewards, and sometimes even money, all of which was their choice to pursue through their labor and time spent on the open source project. The users of open-source projects, upon which the projects themselves depend, are also not obligated to anyth…

People have a right to become angry. They absolutely don't have any right to override the will of a project maintainer.

By the way, isn't this a great opportunity? The code is open. Fork it. Seize the day. Become a better maintainer, and build a community around your fork. Ensure the community needs and wants are aligned with yours. Steer that ship. Gain prestige. And money, maybe.

If someone is a bad maintainer, there will be no community, no prestige, and no money.

Re: A Sad Day for Rust

#364

Post by asjw » Fri, Jan 17, 2020, 4:58 PM UTC

makomk wrote: post #176

deng wrote: post #157

Earlier quoted context omitted.

> Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful. No, if you pay for things, you have a contract and things are immediately different.

So basically, if you use open source code in your code, you should expect there to be security vulnerabilities which people know about and are keeping quiet about because it'd be unfair to the unpaid creator to criticise them? Tbat sure makes it sound like it's morally irresponsible to use open-source rather than purchased commercial code in something like a web-facing service in 2020, especially given what we know n…

> if you use open source code in your code, you should expect there to be security vulnerabilities

You should be able.to fix them yourself

That's the premise of OSS

if you don't want to pay for a cab or a driver, you should be able to drive

Re: A Sad Day for Rust

#365

Post by wfdctrl » Fri, Jan 17, 2020, 4:58 PM UTC

mileycyrusXOXO wrote: post #12

I understand maintaining open source is a lot of work and why someone might want to call it a day - but this is probably the least professional way someone could do it. People depend on this software. It is inconsiderate to just move it to private instead of taking the time to hand it off to someone else. I'm 80% through building an API using actix-web. Time to reassess whether or not I should start over - wonder wha…

If you don't understand how opensource works don't use it. If you paid nothing you are not a client and nobody owes you anything...

Re: A Sad Day for Rust

#366

Post by tomxor » Fri, Jan 17, 2020, 4:58 PM UTC

This all boils down to entitlement...

If you want a committee to answer for maintenance and philosophical debate or whatever, then fork and form an organisation for it... if not, leave people alone ffs, a one person authored project that got popular does not deserve this, abandonment is the only outcome.

Re: A Sad Day for Rust

#367

Post by CoffeeDregs » Fri, Jan 17, 2020, 4:58 PM UTC

While I much appreciate Steve's work on Rust, this does seem a little high on drama and low on substance. Rust really does seem to be a nice language and here for the long haul so bumps in the road are opportunities for improvement rather than moments to sow seeds of doubt. From the link title, I thought that someone had died or that Rust was fundamentally broken, but:

- The internet will be the internet and that's, unfortunately, here to stay.

- Being a maintainer can be a less than thankless job and that's a bummer but also a fact.

- Reddit can be toxic, news at 11.

I had assumed that 'unsafe' was a rarely used aspect of the language (as it is in Haskell and as duck-punching is in Python). It seems necessary (to me). It might be used more often than it should be? Hmm. Okay a little unsafe-coverage tool should allow for quick assessment. Of course, FFI libraries will be heavy on unsafe but use them at your own risk...

All successful software projects pass through previously-small-problem-becomes-big-problem stages ("Argh. Looks like it's time to move from Pivotal to JIRA..."). I don't find Steve's melodramatic response to an opportunity to "level-up" to be particularly helpful.

I do think it'd be great to have an unsafeness analyzer (if there isn't one already) and to expose those values in cargo.rs. And to follow other safeness-flag recommendations in this discussion. Were those in-place or in-flight, most of TFA would have been "the internet has driven away the maintainer of a good project and that's not good".

Re: A Sad Day for Rust

#368

Post by elefantastisch » Fri, Jan 17, 2020, 4:59 PM UTC

solipsism wrote: post #306

elefantastisch wrote: post #189

Earlier quoted context omitted.

Meta-comment: Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based. Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.) Much of what makes…

This is a bit Pollyanna. People aren't logic robots that start from first principles and then derive all knowledge from logical reasoning. People are emotional, irrational beings. Those of us who fancy ourselves rational are constantly involved in irrational motivated reasoning helping us maintain that desired worldview. Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But the…

To the point of "honest people": I added "honest" in editing to distinguish from people who are just arguing because they like fighting and wouldn't agree if you told them 2 + 2 = 4. There are plenty of those online too, and their reasons for disagreeing clearly aren't covered by my "reasons people disagree" principle.

But as I understood you, point taken. The distillation of principles, information, and interpretation into an opinion does not actually occur as idealized in my breakdown. I wouldn't disagree with that.

Re: A Sad Day for Rust

#369

Post by dbcfd » Fri, Jan 17, 2020, 4:59 PM UTC

coleifer wrote: post #63

I am disgusted by the cultural phenomenon of making sarcastic call-out comments on twitter/etc., with an eye towards building up enough community outrage to force an issue. There are people who forget that open-source does not entitle you to anything (read the fucking license). Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without so…

> Maintainers of large projects are not even allowed to have a bad day, to make a brusque comment, or to disagree with a majority -- without someone trying to stir up a lynch mob. It sickens me the lack of balance between the work done by the maintainers, and the expectations of random users.

Sure they are. There's a number of projects out there with a massive caveat on the front page that says "Not for production use". They are then more than free to close issues with comments like "Hey I'm researching a new refcell implementation, thanks for finding this, but I'm more interested in speed than safety at this point."

Actix did not put up a disclaimer, and in a lot of cases, either closed issues/patches without comment, or with a somewhat demeaning comment. It was not just published as a fast and safe production ready web framework, it was promoted as such, so the author should expect patches in that vein.

There were multiple bad actors involved here, but it stems from a maintainer who took issue with anyone finding problems in his code.

Re: A Sad Day for Rust

#370

Post by Accujack » Fri, Jan 17, 2020, 4:59 PM UTC

solipsism wrote: post #306

elefantastisch wrote: post #189

Earlier quoted context omitted.

Meta-comment: Thank you. Online discussion would be much more productive if everyone clearly laid out the principles on which their viewpoint was based. Fundamentally, there are only a few ways honest people can disagree: Different principles, different information, different interpretation, or just plain misunderstanding. (Meta-meta: This is the principle that I believe and based this comment on.) Much of what makes…

This is a bit Pollyanna. People aren't logic robots that start from first principles and then derive all knowledge from logical reasoning. People are emotional, irrational beings. Those of us who fancy ourselves rational are constantly involved in irrational motivated reasoning helping us maintain that desired worldview. Not to say we shouldn't try to live up to the ideal you set forth. We should do our best. But the…

Hey, hey. Speak for yourself.

;-)