A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#231

Post by cerebellum42 » Fri, Jan 17, 2020, 4:16 PM UTC

protomyth wrote: post #103

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…

No one expects you to write perfect code, but we do expect you to fix flaws when you learn about them. Looking at the postmortem[1], it looks like the patches provided were not good enough in the developer's eyes: I believed it held mutable aliasing invariant and I was very happy that someone found real problem. I wanted to solve the problem, just with a bit of creativity. And use RefCell solution only if it would be…

Maybe that is what the developer intended, but afaik it is not what he communicated. What he communicated was a flat out dismissal of the issue along with the proposed fixes. Followed by deleting the whole issue from GitHub. To be fair, there were some very unpleasant things said in there, but he could have just deleted those and maybe locked the conversation telling people about his plans.

This whole thing was a feedback circle of increasing hostility between the community/contributors and this developer. At some points the developer was very unresponsive, leading to disappointment from the community, but then some very uncalled for personal attacks came from the community. I think the developer received some justified criticism, but I still understand his perspective, putting work in and getting abuse back sucks.

Re: A Sad Day for Rust

#232

Post by waynenilsen » Fri, Jan 17, 2020, 4:18 PM UTC

steveklabnik wrote: post #30

spamizbad wrote: post #25

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.

When there is so much discontent in the community a fork is a very natural consequence. This, in my opinion, is open source working well.

https://en.wikipedia.org/wiki/Ethereum_Classic

Re: A Sad Day for Rust

#233

Post by lostmyoldone » Fri, Jan 17, 2020, 4:18 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…

You don't get to invoke professionalism, or lack thereof in regards to some individuals work they've made available for free.

Open source gives you access to source code to do with as you please. Storing your own copy is a good idea if it's something critical to your endeavors. The possibility of having to maintain anything of that nature yourself is always a risk.

Expecting, demanding, or begging for anything except what the author willingly, and happily takes upon themselves is exploitation, pure and simple.

If you think about it, trying to coerce an author/maintainer into doing anything they willingly and explicitly have commited to, is no different than employing bullying, group pressure, and other social/psycholgical manipulation techniques to get whatever outcome others deem useful to themselves.

Yes, something as trivial as complaining about the lack of response to a question can easily be seen as being abusive when there is no established relationship or expectation, no quid pro quo, or similar.

Getting free access to someones work is amazing, and nobody should ever have to face what so many maintainers have to face today in the form of unreasonable expectations and outright bullying.

Re: A Sad Day for Rust

#234

Post by archivist1 » Fri, Jan 17, 2020, 4:18 PM UTC

Open source is fundamentally wrong and in need of a correction. It's an exploitative labor practice.

There's a better way. It's coming.

Re: A Sad Day for Rust

#235

Post by zozbot234 » Fri, Jan 17, 2020, 4:18 PM UTC

lidHanteyk wrote: post #169

Sorry to add yet another top-level thread, but my take on this is that, while it is correct that unsafe-blocks are a central and contributing factor to this incident, it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks. As long as Rust both has such an easy way to circumvent the type system, and a desire to supplant C and C++ on the basis of code quality and safety, there will be read…

> it is incorrect that languages doing what Rust does fundamentally need unsafe-blocks

But they do need those. Even C# has unsafe blocks, and Java has sun.misc.unsafe. It's a rather boring feature actually, the interesting part is what you can assert about safe code, and at what cost.

Re: A Sad Day for Rust

#236

Post by steveklabnik » Fri, Jan 17, 2020, 4:20 PM UTC

JohnFen wrote: post #204

I have to wonder -- is this a real problem in the Rust community? The essay makes it sound like it's just the usual Reddit toxicity.

That’s what I was trying to get at with the “is /r/rust part of the community or not” bit. Inside official spaces, none of this happened. If you don’t read Reddit, it follow certain folks on twitter, you wouldn’t have seen any of this.

Re: A Sad Day for Rust

#237

Post by amyjess » Fri, Jan 17, 2020, 4:20 PM UTC

TheRealDunkirk wrote: post #186

lallysingh wrote: post #111

Earlier quoted context omitted.

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.

> Why is the maintainer responsible for that? It just seems to me that there's a give-and-take to being the maintainer of a popular open source project. You get help on the project in the form of people contributing patches, right? Doesn't simple human curtesy and a modicum of wisdom suggest that you should explain your rationale in accepting or rejecting them, to manage expectations, so that it doesn't end up like t…

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 just to reinforce my "you take what you can get" policy.

Re: A Sad Day for Rust

#238

Post by endorphone » Fri, Jan 17, 2020, 4:21 PM UTC

izacus wrote: post #145

deng wrote: post #100

Earlier quoted context omitted.

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.

> 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. Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security. Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.

This has been the argument throughout the various discussions -- that somehow if there isn't a payment structure between party A and party B, there is full immunity from criticism, questioning, expectations, etc. It is absolutely insipid and is a logical non-starter that doesn't pass the most basic of considerations. Yet it keeps recurring. It's bizarre.

Re: A Sad Day for Rust

#239

Post by tus88 » Fri, Jan 17, 2020, 4:21 PM UTC

LOL rust is a shit language that will never replace C, and this situation was entirely predicted by doubters, despite the assurances of rustophiles who claimed unsafe was not a problem, won't be abused etc.

The emotion unveiled by this incident shows a deep anxiety in the rust community that the doubters are correct.

C forever!

Re: A Sad Day for Rust

#240

Post by pertymcpert » Fri, Jan 17, 2020, 4:21 PM UTC

blackearl wrote: post #18

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…

I'm sure both sides are being childish here. Users thinking they can abuse a dev because they know better, and devs deciding they'd rather take their ball and go home. No one looks good at the end of this situation.

Your analogy is stupid. People are still able to fork the project. Taking the ball and going home means that you prevent everyone else from playing,