Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

141–150 of 1001 posts

Re: A Sad Day for Rust

#141

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…

Do you think we get software like zlib and libjpeg and BLAS and linpack by people shrugging off working for the community and failing to fix bugs?

Otherwise we get dozens of half broken forks all over the place. That's no fun for anyone.

This wasn't a drive by beg. This was a patch solving real demonstrable problems and at minimum there should have been a transition plan due to basic decency.

Re: A Sad Day for Rust

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

How is taking your ball and going home childish when an angry mob is after you? Seems like a rational response to me.

Re: A Sad Day for Rust

#143
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. 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 play the but-I-dont-get-paid-card. You can resign gracefully and let other people take over. If you put up a tantrum, you probably get your reputation burnt faster than a Google project gets when they suddenly pull the plug.

Open source is not some backyard game anymore. It involves companies and their commitment in form of infrastructure and participation.

Open source is like capitalism. But a project's success is measured in commitment instead of capital.

Re: A Sad Day for Rust

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

On the consumer-dev side, more forks make discoverability much harder. It really helps when there's a canonical place to find a given piece of software. Having to follow comment threads across various platforms to find the most stable version with that feature you want is a huge pain.

Also the core dev(s) for larger projects are usually somewhat responsive, whereas devs who fork to add their one feature usually aren't signing up for that core maintainer experience when they do so.

Re: A Sad Day for Rust

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

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

Re: A Sad Day for Rust

#146
To start: any personal attacks against the author are unacceptable. Anyone is free to write whatever the code in Rust they like, and it is wrong to attack them about it.

But .... I think it is showing that the premise of memory safety in Rust is working. Stuff that would go unnoticed in C and C++, is being identified and called out in Rust. Does it lead to drama, personal conflicts, etc.? Maybe. But from the perspective of the potential Rust user it's a proof that it `unsafe` keyword works, leads to higher scrutiny of potentially dangerous patterns and that the culture of other Rust users takes reliability, security and safety seriously.

Re: A Sad Day for Rust

#147
post #17

Earlier quoted context omitted.

You can take a look at the actix-web repo, which has been wiped. A message has been added: https://github.com/actix/actix-web/

Repo wiped after receiving criticism. I think I'm beginning to see another side to the story other than reddit being a swarm of jerks.

My thought exactly. While the reddit swarm was probably harsh, it sounds like it was actually a shit project and it's probably good that it's dead

Re: A Sad Day for Rust

#148
Hopefully someone with a clone of the project can spin off a "reactix" fork.

I don't think the negativity was necessary, that said, if it wasn't a significant impact to performance but did potentially improve safety, many of the patches should probably have been brought in.

Personally, I've been more drawn to the likes of Rocket and Yew. The former for the server because I really like the interfaces and usability. The latter, I haven't done much with, but think it's pretty cool and a relatively small starting point for a WebAssembly based UI experience, compared to say Blazor.

Re: A Sad Day for Rust

#149

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.

If a fundamental plank in rust's safety platform involves "apply the honor system to random people on the internet who swear they've vetted something", then that's a problem.

Re: A Sad Day for Rust

#150

> “Why Reddit is like this” is a whole other essay; I think it’s built into reddit’s structure itself. Classic Eternal September. Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new u…

> the [psychological] profile ... is one built on abrasiveness, distrust and aggression towards authority,

Hey hey hey, "aggression towards authority" is not a psychological trait, but at most and pattern of action. Also, I disagree with your implicit maligning distrust of authority without generally distrust of others.

> ... and participate in social contract,

The claim of the existence of a "social contract" is part of the self-justification of authoritarian aspects of social structures in capitalist democracies.

Post reply on HN