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

Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

gist.github.com

Post reply on HN
Print view View original

131–140 of 245 posts

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#131

Post by ghusbands »

xyzzy_plugh wrote: post #88
klelatti wrote: post #82

Earlier quoted context omitted.

> bug ridden garbage > expect to be treated kindly Do you see why the first might make someone doubt the second?

I didn't give that feedback to a contributor. I didn't encourage maintainers to insult contributors. If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage. It takes time and patience to refine it into something good. It doesn't mean you shouldn't try. If you , or anyone else -- colleague, stranger, whatev…

Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind, which will be visible in other ways and will turn some people away. It can help your outlook on the world and your impact on others to make an effort to think less negatively.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#132

Post by klelatti »

xyzzy_plugh wrote: post #95
klelatti wrote: post #63

Earlier quoted context omitted.

> The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. Whether or not you are right on this issue is this really the way to generalise about current / potential contributors? Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Edit: I’m making no point about quality or otherwise of cont…

Since you edited: I think you're misconstruing what I'm saying. I'm not selling an atmosphere. I'm writing a comment on this website. I don't have a project for you to decide to contribute to. I don't think anyone is suggesting that anyone's efforts should be dismissed impolitely -- but that's not what's being discussed here.

'Most programmers / contributors can only produce bug ridden garbage. Not you obviously!'

Can you see the issue here?

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#133

Post by throwawayffffas »

tayo42 wrote: post #127

This is part of what i think is a problem with rust. Where all of these important features are left to volunteers in the community to come up with. A lot contributors seem to be unprofessional or hobbyist/amateurs. Like some of these issues in the pr really aren't "perfectionism". Then this guy trying to make projects look bad seems childish because he isn't that great at programming. Maintaining a open source projec…

It looks to me that the maintainers straight up don't think the feature is important. But the author seems to miss the fact that by making a PR he is actually creating a burden for the maintainers. They are not in anyway obliged to merge it or even look at it. If he actually cared and wanted to contribute he would look for bugs not for new features. The way I see it new feature development is a right to be earned in a codebase you can't show up and expect people to review the code and merge it because it would look great in your cv or because it takes care of that one use case you care about.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#134

Post by DannyBee »

Etheryte wrote: post #77
klelatti wrote: post #63

Earlier quoted context omitted.

> The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. Whether or not you are right on this issue is this really the way to generalise about current / potential contributors? Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Edit: I’m making no point about quality or otherwise of cont…

As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, and from the offset it's often not so straightforward to figure out which one you're dealing with. It isn't constructive to think of a contribution as a gift, if anything, it's a Greek gift [0]: contributing to an open source project creates more work for the m…

"As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, "

I've contributed to hundreds of projects, and maintained a ton, so i feel this pain, so please take what i say in that vein :)

The question i usually ask when i see this is: "What is the thing you did that you think should have caused people's behavior to change?" Assuming you want this to be different, what actions are you taking that should have changed this? If they didn't, what did you learn and try?

I'm not suggesting you will get to some perfect place where all contributions are great, but if you really want to improve them overall, you have to be doing things to improve the behaviors you see, seeing whether they work, and iterating, until you get the behavior you want out of most contributors.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#135

Post by brabel »

cryptoboy2283 wrote: post #74
brabel wrote: post #9

I wrote a blog post showing how Rust performance can be pretty terrible when you write code like you would in other languages (something people recommend to beginners to avoid having to deal with advanced concepts in Rust)... big mistake: I am pretty sure several dozen "Rustaceans" felt the need to write to me explaining how terrible my code was, how it could be much faster if I just did x and y (which were true, but…

Could you share the link to your blog post?

Are you joking? Do you want to join the angry crowd?

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#136

Post by tomxor »

Etheryte wrote: post #77
klelatti wrote: post #63

Earlier quoted context omitted.

> The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. Whether or not you are right on this issue is this really the way to generalise about current / potential contributors? Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Edit: I’m making no point about quality or otherwise of cont…

As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, and from the offset it's often not so straightforward to figure out which one you're dealing with. It isn't constructive to think of a contribution as a gift, if anything, it's a Greek gift [0]: contributing to an open source project creates more work for the m…

A lot of disgruntled contributors also forget that beyond code quality, projects have opinions, and their PRs opinions may be incompatible... We need to be grateful even when maintainers disagree with us, because opinion soup makes for bloated, unfocused, buggy, crappy software.

Perhaps this part explains all the commotion around rust... being a popular new language with strong opinions, but today there is a lot of entitlement going on in software communities, assuming that it makes sense to integrate inclusivity to such a degree that it's actually incompatible with what makes a cohesive opinionated project.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#138

Post by wyager »

klelatti wrote: post #63
xyzzy_plugh wrote: post #39

> So, here we are in 2020, and nix#864 remains unmerged. Fred, you say, you overreact. I read the entire PR. I _want_ to agree with the author, but I didn't find this reasonable. The feedback, for the most part, was not about being perfectionism. Not remotely. It's about being correct . This is not unique to Rust, which as a language spends a lot of time being correct in a few dimensions, but pretty traditional. You…

> The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. Whether or not you are right on this issue is this really the way to generalise about current / potential contributors? Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Edit: I’m making no point about quality or otherwise of cont…

> Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?

I think most people who can make positive contributions are aware that they can do so. There are also a bunch of people who can't but think they can, which is fine, but they need to be understanding when their PR gets feedback or turned down outright.

Contributing to someone else's project is both a gift and a burden for the maintainer, so contributors need to have humility about the net value of what they're contributing. If code isn't up to the maintainers' standards, the imposition on the maintainers may exceed the value to the project. If this isn't a risk a submitter can tolerate, it's unlikely that their contribution would be a net positive.

Most communities have healthy expectations about participation in certain activities being contingent on a certain level of experience/skill so that participation does not impose an undue risk or cost on the community. Open source post-2010 has a very abnormal and unrealistic ideal of encouraging everyone to be involved at all points in the process at every skill and experience level. It's perfectly reasonable to have a feedback mechanism where you tell people to get good/lurk more/work on their backhand/etc. before engaging with the community at a certain level, so as to prevent the cost of managing their contribution from exceeding its value.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#139

Post by coldtea »

ghusbands wrote: post #131
xyzzy_plugh wrote: post #88

Earlier quoted context omitted.

I didn't give that feedback to a contributor. I didn't encourage maintainers to insult contributors. If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage. It takes time and patience to refine it into something good. It doesn't mean you shouldn't try. If you , or anyone else -- colleague, stranger, whatev…

Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind, which will be visible in other ways and will turn some people away. It can help your outlook on the world and your impact on others to make an effort to think less negatively.

>Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind

Or an accurate depiction of reality.

Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)

#140

Post by DannyBee »

xyzzy_plugh wrote: post #39

> So, here we are in 2020, and nix#864 remains unmerged. Fred, you say, you overreact. I read the entire PR. I _want_ to agree with the author, but I didn't find this reasonable. The feedback, for the most part, was not about being perfectionism. Not remotely. It's about being correct . This is not unique to Rust, which as a language spends a lot of time being correct in a few dimensions, but pretty traditional. You…

Speaking as a historically pedantic person, correctness is often a form of perfectionism. Just gussied up.

Unless you have a verifiable system all the way down, you will always have bugs, crashed, and race conditions.

Going all the way to 11 on trying to make it correct usually results in negligible improvement in correctness for a lot more time spent. Depends on the system of course. This is a terminal emulator, not a rocket ship.

I'm not suggesting you should just have totally bug ridden code, but if you are putting people through years of in-PR iteration on a thing to achieve "correctness", either 1. Close it because you won't get what you want 2. Accept it and improve it prior to release.

I'd point out: If it is really this hard for reasonable programmers to get it "correct", do you really think the people on the other side of the PR are so good at programming that they are getting it all right too?

Post reply on HN