Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Sad Day for Rust

words.steveklabnik.com

Post reply on HN
Print view View original

651–660 of 1001 posts

Re: A Sad Day for Rust

#651

Post by fsckboy »

zzzeek wrote: post #612
munificent wrote: post #512

Earlier quoted context omitted.

People are not robots, but in terms of reaching agreement between humans, "emotion" is more or less just a difference in priorities, which is one of the ways reasonable people can disagree. If we agree on the facts and we agree on their implications, but we still disagree, it's likely because we weight things differently. Emotions are simply a large component for how we weight things.

emotionalism is strongly linked to irrationality. once someone is irrational I'm not following how that can be reduced to a "difference in priorities". I'm an open source maintainer of some very popular projects. more in the early days, I was certainly irrational on a few occasions where someone called out things that I did wrong and I refused to see it. It wasn't like I had de-prioritized "making sure the code is no…

But rationality (in the human sense) is completely governed by emotion. Curiosity about an unsolved problem? that's emotional regulation of the brain. Satisfaction that a problem is solved? also emotion. Beauty in a better solution? emotion.

This has significance, it's not just a restatement of "the problem" using different terminology. It's significant because the brain, like every other part of the body, evolved parsimoniously, and it does not have spare capacity lying around, so anything that "distracts" the emotional parts of the brain will diminish rational capacity. "Hangry" is not just a pun/quip about being hungry, it's empirically measurable, it affects outcomes.

Debating rational topics with your rational friends, whether at work, at school, or after hours over a beer, it's fun (emotion), can be frustrating (emotion) but does it ever not get heated (more emotion)?

The brain is an emotional organ. All the other organs are rational, they do what they do in entirely predictable and logical ways.

Re: A Sad Day for Rust

#652

Post by xscott »

pdimitar wrote: post #624
xscott wrote: post #613

Earlier quoted context omitted.

> The OSS maintainer should clearly, upfront, preliminarily, outline how do they govern the project Why do you think they owe you this? You didn't pay them, and they didn't accept a contract.

I don't feel I am owed this at all. I feel only that it's being a good open-source citizen. When you make something that people use and like and want to improve, you should at least have the common decency to tell them beforehand: "this is my show, not gonna accept PRs". I don't think it's such an exhausting job to write two lines at the top of the README.

Appealing to "common decency" is just the same as "being owed". I think you're mincing words to avoid sounding entitled, and I don't think anyone is even entitled to two lines in a README, much less at the top.

Re: A Sad Day for Rust

#653

Post by pdimitar »

xscott wrote: post #652
pdimitar wrote: post #624

Earlier quoted context omitted.

I don't feel I am owed this at all. I feel only that it's being a good open-source citizen. When you make something that people use and like and want to improve, you should at least have the common decency to tell them beforehand: "this is my show, not gonna accept PRs". I don't think it's such an exhausting job to write two lines at the top of the README.

Appealing to "common decency" is just the same as "being owed". I think you're mincing words to avoid sounding entitled, and I don't think anyone is even entitled to two lines in a README, much less at the top.

All I am doing is saying that it takes very little effort to be upfront and hopefully avoid future confusion. You are free to disagree. ¯\_(ツ)_/¯

Re: A Sad Day for Rust

#654

Post by AaronFriel »

This is very difficult. I feel badly for the author of actix-web, and I agree with Klabnik to the extent that Reddit can be a terrible place.

What I think this is, is a sad day for the Rust community.

But it is probably a good, and necessary step for the Rust ecosystem. The bottom line is the creator of Actix made something really attractive, but not necessarily good¹, which pulled a lot of people in to using it. It did extremely well on benchmarks, which brought Rust positive attention.

But the project was fatally flawed unless another maintainer forked it. The author was not obligated to accept patches from anyone else, but it was and should be unacceptable to the Rust ecosystem for the most popular web framework to have severe vulnerabilities that can be exploited. And for the author and maintainer to disregard patches to those issues as "boring" or other derisive terms should also be considered unacceptable.

Perhaps that would have been the right way to fix this actix-web issue, to produce a better project. This is basicaly what happened with cabal (package manager for Haskell) and stack (a wrapper that made it easy to build Haskell packages). But at the same time I can't in good conscience recommend anyone use cabal, nor could I recommend anyone use actix-web. It may very well be for the best that they just won't be used.

¹ - Good has lots of different connotations. Is there a lot of code? Yes. Is it largely well written? I think so, based on what I've heard. But in the long term having a benevolent dictator for life controlling a major piece of the Rust ecosystem is extremely dependent on them being benevolent, and rejecting critical security fixes and declining to engage the community in any meaningful way is not this. On the other hand, I think projects like async-std and tokio have a much more benevolent (and less dictatorial) leadership.

Re: A Sad Day for Rust

#655

Post by sigstoat »

PhaseLockk wrote: post #569
cmsj wrote: post #530

Earlier quoted context omitted.

> if you write one, advertise one, you need to care about security The word "need" there is wrong. You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. If you want those obligations, get a contract and pay some money. What's happened here, and you seem to have fallen…

> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything. I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different ba…

> I was taught that part of being an engineer taking a moral responsibility for the safety of your creations.

almost certainly in the framework of being employed or contracted to do engineering work. go back and ask your teachers what they felt they owe people asking them to design things unpaid, in their free time.

Re: A Sad Day for Rust

#656

Post by strbean »

_-___________-_ wrote: post #352

I've written a lot of Rust code that's in production in web, messaging and telephony contexts. I considered using Actix early on, but as soon as I saw the large amount of unsafe code, I stopped considering it at all. I did not go on the Internet and try to convince other people not to use it. I did not complain at the maintainer that he should manage his project differently. I just didn't see why a library doing what…

I have to question your position from a moral standpoint though.

If you were a rollercoaster engineer, and you saw that a rollercoaster had an unsafe design, would you follow a similar approach? "I'm not going to ride that, but I'll let this line of people ride it without warning them." Obviously the stakes are wildly different, but still...

Re: A Sad Day for Rust

#657

Post by mongol »

ratherbefuddled wrote: post #637
neosat wrote: post #424

Earlier quoted context omitted.

In addition to the (great) framework you listed, there is another big factor - incentives. You may be aligned in principles, have the same info etc. but if your incentives are misaligned it can be hard to agree.

Surely a disagreement based on incentives is not an honest disagreement?

I think disagreement on incentives plays out as how prioritized something is viewed. I may agree that something is wrong, but not worth it for me to fix during a weekend because I don't get paid overtime for it. As an example.

Re: A Sad Day for Rust

#658

Post by kbenson »

rakoo wrote: post #586
ambrice wrote: post #531

Earlier quoted context omitted.

So, your advice is that if you care about security even a little bit, you should write all your software from scratch yourself?

I think it means you should look more closely into the contract you have with the maintainers. Either you rely on trust, like you would do if you used OpenSSL or NaCl because the creators and maintainers are known to go beyond the required minimum, or you get an official contract.

This. There is no free lunch. Either you pay for quality or assurance, or you risk you might get something rotten that wasn't obvious at first glance and you can't do anything about it. That's the difference, when you pay, you might also get something rotten, but you can do something about it. Your options are of course only constrained by what you pay.

The problem, as I see it, is that a whole generation of programmers have grown oblivious to this implicit relationship, and when that relationship is actually exercised in some way, they default to what they understand, which is paid services and products, which results in both sides feeling like they got a raw deal.

Re: A Sad Day for Rust

#659

Post by rukittenme »

zozbot234 wrote: post #635
rukittenme wrote: post #444

I want to add two (maybe very) controversial comments. 1). It should be considered RUDE to contact a solo maintainer in any way relating to the project (email, issue, pull request, etc.). You should ALWAYS fork the project and use the forked project on your own terms. Most people write their projects, on a whim, on a Saturday, for a bit of fun. They do not want to be shackled to a hobby for the rest of their lives. 2…

A maintainer that you can't reach out to is no maintainer at all. If that's the behavior they expect from others, they should clearly state that the project is not being maintained, and be open to others taking up that effort instead.

> they should clearly state that the project is not being maintained

A project by a solo, unpaid author should be presumed unmaintained.

Re: A Sad Day for Rust

#660

Post by oaiey »

Wowfunhappy wrote: post #614
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…

> Open source participants are volunteers and owe you nothing. I can't agree. Not for all participants. Let's take Linus. He's in charge of the Linux project, which thousands (millions?) of people contribute to every day. If Linus suddenly stopped merging any and all patches—but refused to officially step down—what do you think would happen? Oh, the project would more than survive—someone would fork it and that would…

Linus is paid to carry that responsibility. Others are not.
Post reply on HN