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

81–90 of 245 posts

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

#81

Post by duckerude »

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…

I actually have experience with this specific code. I recently fixed a bug in a function that his PR also touches: https://github.com/nix-rust/nix/pull/1521

And I have a PR to fix problems in another Rust wrapper of the same libc functions: https://github.com/uutils/coreutils/pull/2653

It's hard to get right. Skimming the PR, the feedback looks reasonable.

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

#82

Post by klelatti »

xyzzy_plugh wrote: post #70
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…

I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time. I've seen some truly impressive contributions over the years and the common element that stands out isn't the au…

> bug ridden garbage

> expect to be treated kindly

Do you see why the first might make someone doubt the second?

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

#83

Post by oreally »

xyzzy_plugh wrote: post #70
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…

I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time. I've seen some truly impressive contributions over the years and the common element that stands out isn't the au…

'patience' that's why these projects never get many things moving forward and those higher up in the project's hierarchy seem to contribute way more. Also this is why younger, hungrier contributors should avoid these types of organizations and why these orgs will suffer sooner or later from certain bias.

Ever heard of the quantity vs quality pottery story? You want to make mistakes and iterate on those to quality. Get the software working, then worry about styles and idiomatics. That seems lost on people nowadays.

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

#84

Post by [deleted] »

buro9 wrote: post #12

A PR is a gift and a burden. A gift of someone else's effort to contribute and push something forward. A burden because once received, future maintainance of the gift is really on the one who received the gift. It may as well be the gift of a kitten... you now have to look after the kitten for the next 12-15 years. Is it socialised? House-trained? How much effort does this take when there are also gifts of other anim…

[deleted]

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

#85

Post by YorickPeterse »

c7DJTLrn wrote: post #24
ay wrote: post #20

Earlier quoted context omitted.

I think a lot of people treat the merge of a PR as their god-given right. Because they spent time on it. But if they spent the time without discussing with the maintainer first, why would they be obliged to merge it ? It is like spending a ton of money on a big, bulky, but useless to a recipient present, giving it to someone and then complaining that they don’t take it - you had spent all this money! The way out of t…

>I think a lot of people treat the merge of a PR as their god-given right I've never seen this at work or in open source, and I've done quite a bit of open source. Contributors will get frustrated if their PR is simply ignored and I think for good reason. But I've never seen anyone say or even imply that their PR must be merged.

I've run into this myself: a contributor submitted a pull request that didn't follow a bunch of guidelines, and the changes they introduced were very different from the rest of the code in the same file. I asked them to keep things consistent with the existing code, and they basically argued "This fixes the problem, so you must merge it".

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

#86

Post by nchudleigh »

thenoblesunfish wrote: post #79

I use Alacritty exclusively, and knowing that the maintainer is discerning makes me like it even more. I'm getting what I signed up for, which is a project which cares deeply about doing a few things very well. I think that an unstated implication of that ethos is that there will be plenty of things that you would like to do, but upon some amount of investigation don't see how to do well enough, so you don't do them…

In this camp, my tty needs are simple. Alacritty is simple- and works well.

IMO core maintainers call the shots on what to accept and what not to. As others have mentioned, if you don't like it- fork and build your own.

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

#87

Post by skrebbel »

This smells a lot of the classic "Worse is Better" discussion [0]. Back then, it was Scheme people insisting on correctness and C people insisting on pragmatism. It's no surprise to me that Rust, a language with a heavy focus on correctness, attracts the correctness-over-pragmatism crowd.

The author is a "worse is better" programmer who finds themselves surrounded by "the right thing" people. I think the addendum the author adds a year later in the top comment is the right insight: fork away. This keeps the "the right thing" people happily obsessed with getting everything right, without the author being blocked on moving faster.

[0] https://dreamsongs.com/RiseOfWorseIsBetter.html (1991)

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

#88

Post by xyzzy_plugh »

klelatti wrote: post #82
xyzzy_plugh wrote: post #70

Earlier quoted context omitted.

I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time. I've seen some truly impressive contributions over the years and the common element that stands out isn't the au…

> 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, whatever -- submitted bug-ridden garbage, I'd spend time and energy to review your contribution, give you constructive feedback to the best of my ability, and hope for the best.

Hell, most _production_ software is bug-ridden garbage. I've written lots of bug-ridden garbage. I'm just calling a spade a spade.

If this turns you off contributing to open source, I don't know what to tell you. It's just reality.

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

#89

Post by temac »

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…

While the comment was overgeneralizing, the code will be rejected (actually, it won't even be rejected in a final way, just feedback will be given about how provide a better version that has chances to be integrated) if the code has actual problems (or at least perceived problems in the eye of the maintainer but in some case we are talking about concrete actual correctness problems that are not a matter of opinion but of pure logic), not just if there is an hypothetical risk that problems would be found if the code was reviewed.

The efforts are mostly irrelevant if the result has serious problems.

And the maintainers also spend some effort to provide the feedback. Which is fair if they say they are open to contributions: effort is provided by contributors, they provide efforts to review. What they can't do, is magically make contributors good enough.

So anyone can attempt to contribute if they are ready to take seriously into account the feedback. In case of over-the-top maintainers who are not reasonable about what they want esp. if this is not about logic defects but about vague opinions, yes obviously you don't have to contribute to their project once you figure out they are chronically unreasonable.

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

#90

Post by jpe90 »

"The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.

Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager.

As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.

If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them.

Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it. All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement."

https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

Post reply on HN