A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#411

Post by [deleted] » Fri, Jan 17, 2020, 5:15 PM UTC

dbcfd wrote: post #369

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 us…

[deleted]

Re: A Sad Day for Rust

#412

Post by flatline » Fri, Jan 17, 2020, 5:15 PM UTC

eropple wrote: post #380

jakear wrote: post #357

Earlier quoted context omitted.

Did the patches obviously maintain the exact same behavior? If so, why should the author care about them? If not, it’s not the author’s responsibility to ensure they’re correct patches, but it is the author’s responsibility to ensure their package is correct. If it was correct already (not sure about this, but it seems it was very popular and used in production, so I imagine it worked well), they have no responsibili…

> I would be very unlikely to accept a patch that simply changed the internal typings for the abstract goal of “fewer any”s. Why would you possibly not? Increased correctness, no change in runtime behavior, and a resistance to code rot and mistakes on your next concrete change. Passing up on such a PR would almost immediately disqualify a library from further use unless I could manage a fork.

> no change in runtime behavior

That's the problem: how does the maintainer guarantee this? And when flooded with multiple such PRs, the task rapidly becomes overwhelming. If you have a robust suite of unit tests and a CI system you have better guarantees but still about as much work to ensure the new functionality is properly tested. That's not to say the maintainer's attitude in this case was excusable, but it's his project and this style of maintenance is definitely not for the feint of heart.

Re: A Sad Day for Rust

#413

Post by [deleted] » Fri, Jan 17, 2020, 5:15 PM UTC

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…

[deleted]

Re: A Sad Day for Rust

#414

Post by zvrba » Fri, Jan 17, 2020, 5:15 PM UTC

jimbokun wrote: post #96

manish_gill wrote: post #26

Earlier quoted context omitted.

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

Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients: https://medium.com/@shnatsel/smoke-testing-rust-http-clients... Skimming this, the author doesn't really like any of them. Note, however, the long list of issues reported at the end of the article. Here is the first one I clicked on: https://github.com/algesten/ureq/issues/24 The maintainer is happy to get the report, and has an exchange w…

> Ok, so here is the article Klabnik cites, comparing various Rust HTTP clients:

Interesting. I'm being led to believe that the actual problem lies in HTTP itself: it is too convoluted to be safely implementable and should be replaced with something else for security-critical applications. (Or in general.)

Re: A Sad Day for Rust

#415

Post by School-Cotton » Fri, Jan 17, 2020, 5:15 PM UTC

zelly wrote: post #378

School-Cotton wrote: post #310

Earlier quoted context omitted.

The set of all computer programs is countable, so I don't think there can be uncountably many ways to have memory errors.

That seems right. Memory errored programs are a subset of all computer programs. The possible runtime states of a program (expanding every branch/subroutine recursively over all threads) is uncomputable. (Otherwise we would have a solution to the halting problem and be able to correctly free memory at compile time.) I'm not sure if that's the same as being uncountably infinite. It's probably a different concept.

Uncomputable is indeed a totally different concept from uncountably infinite.

Re: A Sad Day for Rust

#416

Post by aazaa » Fri, Jan 17, 2020, 5:15 PM UTC

> So, someone takes a peek under the covers, and it turns out actix-web is using a lot of unsafe code. That’s not inherently a problem. The problem is, a lot of that unsafe code is not actually needed. This is where things start to go wrong.

Can anyone link to a discussion in which the actix-web maintainer explains his position at a technical level?

The article leaves me baffled at why the maintainer was so unreceptive to concerns about the use of unsafe.

Re: A Sad Day for Rust

#417

Post by notyourday » Fri, Jan 17, 2020, 5:17 PM UTC

nevi-me wrote: post #321

ddevault wrote: post #83

Earlier quoted context omitted.

>the community is extremely validated in saying "Hey this library in a language that professes security isn't secure and the maintainer doesn't seem to care" Yes, but that's not what they said. They were hateful and virtrolous, which is never appropriate. Fork it and fix the problems, create a new library which has the same API but is more sound, promote an alternative library in its place, offer to lend a hand in ma…

Counter: what about the tension and potential community split when a fork starts getting popular? I was there (as a user who closely followed development) during the nodejs > io.js split. While it worked out in the end, it felt like a bitter battle at first. Node survived by chance perhaps. We have our async-std vs Tokio right now, I'd imagine having another split (at least in opinions and preference) on actix would…

nodejs io.js split was a great evolutionary step.

It allowed for the chaffs to fall through making node a stronger project because it was clear that neither of the sides was going to "win" outright.

If the argument is that "maintainer is not doing his/her job of being a maintainer" and this argument is accepted by the users, then should the project be forked by someone who will do his or her job of being a maintainer, the users will flip their source repo pointer and move onto the fork effectively killing the original.

Re: A Sad Day for Rust

#418

Post by herbstein » Fri, Jan 17, 2020, 5:17 PM UTC

steveklabnik wrote: post #139

jimbokun wrote: post #108

Earlier quoted context omitted.

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

That comment is demeaning, unhelpful, and in very bad taste. It's the comment that the delete functionality on GitHub was made for. However, one of the other participants in the thread immediately called out this comment. So you have a constructive dialog, a single bad actor, and said single actor being called out by the people having the constructive dialog. That doesn't sound like an unhealthy community to me, to be perfectly frank.

Re: A Sad Day for Rust

#419

Post by weberc2 » Fri, Jan 17, 2020, 5:17 PM UTC

throwlaplace wrote: post #374

weberc2 wrote: post #355

Earlier quoted context omitted.

I reject the axiom. No one is above criticism provided the criticism is rooted in fact (i.e., defamation is not criticism).

it's not about whether someone is above criticism - it's about whether criticism makes sense in the context of what's being proffered. in another part of this branch of the thread i make the analogy with a an artist's sketch posted to a public art gallery. it's not that you can't criticize, it's that it doesn't make sense to criticize because the artist isn't attempting to achieve anything. maybe a better analogy is…

That’s not the issue at all, and we know this because the project was advertised as secure and the critics were arguing that it wasn’t advertised as such. This is characteristically different than your basketball analogy because it is neither explicit nor implicit that the project was unsuitable for production. Drew is arguing that the criticism is invalid because maintainers are within their rights to even lie about their projects because all responsibility lies downstream. Note that security DOES indeed lie downstream, but Drew is mistaken for arguing that this downstream responsibility immunizes maintainers from such criticism. This is a non sequitur.

I don’t understand the desire to make this out to be a sort of dichotomy—both groups have the right to do what they did (the maintainer to reject patches and even allegedly lie about the security properties of his project and the critics to criticize even in bad taste) and both parties could have handled it better. TFA did a fine job for implicitly acknowledging this by simply referring to the situation as sad all around.

Re: A Sad Day for Rust

#420

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

Traster wrote: post #254

withoutboats wrote: post #89

This situation is the sad and absurd result of two processes going on in the Rust community. The first is that the Rust community on Reddit is in a feedback loop of groupthink and outrage, making it into a powerful vector for harassment. The maintainer of the actix project had a particularly terrible experience of escalating harassment from the users of this subreddit, and its extremely sad. This has caused a lot of…

That article from Shnatsel is really stunning, just everything about is negative and snarky- to a comical point. His avatar is a cartoon pony doing a facepalm! I find it kind of funny that the author of this has singled out reddit for criticism when seemingly prominent members of the Rust community are perfectly willing to be so openly toxic.

Being negative and snarky about crappy, hacked-together code that might cause security issues all over the place is not a bad thing. Yes, most of the snark there is about 'http' crate with its weird custom implementation of basic data structures.