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

11–20 of 245 posts

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

#11

Post by AlexanderDhoore »

c7DJTLrn wrote: post #6

I think many developers treat PRs as an opportunity to gatekeep. I'm not a very politically correct or emotional person but I think gatekeeping/nitpicking is extremely demotivating and it should be avoided wherever possible. When I review PRs, I'm looking at the big picture. I'm looking to see if it introduces security issues or diverges from standard practice. I don't care if there's a slightly better way which redu…

What about adding it to the PR yourself? Why should it be the same person creating/fixing the PR?

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

#12

Post by buro9 »

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 animals stacked up behind this one?

I don't think it's constructive to paint the approver as gatekeeping, or perfectionist. What does that achieve? Surely it's better to meet halfway on the gift exchange, thank you for the PR but it does need to be house-trained and socialised, etc.

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

#13

Post by erk__ »

Grumbledour wrote: post #4
maxekman wrote: post #3

Ah! The “classic” ligature issue. Have been following that for a while. Kind of given up hope that there will ever be any support for it. Edit: punctuation

Indeed. I also switched to Kitty a long time ago. While I personally would like a tty with less features overall, this one was absolutely a deal breaker for me.

There is also Wezterm which does have support for ligatures https://github.com/wez/wezterm

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

#14

Post by hiyer »

I used to use kitty, but its CPU usage was on the higher side on my laptop. I tried alacritty but the lack of tabs (after using kitty for a long time) was a deal-breaker. I'm currently using Wezterm[1], another rust-based terminal, which has tabs. It's worked great for me so far.

1. https://github.com/wez/wezterm

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

#16

Post by an_ko »

As a free software maintainer, I have high standards for quality because (a) I like it that way, and liking it is why I do it for free, and (b) if your PR sucks, chances are I'm the one who has to write the docs, fix the bugs, and deal with the design consequences forever.

If you disagree with maintainer priorities, just fork it! Merge whatever you want, advertise your fork in the unmerged PRs' comments, see what happens. Nobody will be offended; the license specifically encourages this.

Maybe you'll find you're just better at this maintainer thing and the world now contains better software, or maybe after a few years you'll find that you understand their perspective.

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

#17

Post by brabel »

c7DJTLrn wrote: post #6

I think many developers treat PRs as an opportunity to gatekeep. I'm not a very politically correct or emotional person but I think gatekeeping/nitpicking is extremely demotivating and it should be avoided wherever possible. When I review PRs, I'm looking at the big picture. I'm looking to see if it introduces security issues or diverges from standard practice. I don't care if there's a slightly better way which redu…

> if I see it as worth changing I'll do it myself after the merge.

100% agree! Someone unfamiliar with the code base takes the time to make a change that improves something, for free and without asking for anything in return... I always try to take it as it is, only asking for changes that are really necessary to avoid bugs or serious problems, then I normally go and do a post-merge cleanup to try to keep things organized in the way I want (which is hard for outsiders to do themselves).

> There's too many ways to do things.

Exactly! That's why Rust PR reviews are always dangerously close to descending into nit-pick shit shows - there's ALWAYS a 0.1% nicer way to write something, you can always change it to make it 2% more efficient, or to avoid allocating as much memory, or avoid using explicit lifetimes, or avoid dynamic dispatch.... the list goes on.

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

#18

Post by c7DJTLrn »

AlexanderDhoore wrote: post #11
c7DJTLrn wrote: post #6

I think many developers treat PRs as an opportunity to gatekeep. I'm not a very politically correct or emotional person but I think gatekeeping/nitpicking is extremely demotivating and it should be avoided wherever possible. When I review PRs, I'm looking at the big picture. I'm looking to see if it introduces security issues or diverges from standard practice. I don't care if there's a slightly better way which redu…

What about adding it to the PR yourself? Why should it be the same person creating/fixing the PR?

I'm assuming you mean't "why shouldn't". Because a lot of critique in programming is a matter of personal opinion and I see it as impolite to block somebody else's hard work because it doesn't look the way the reviewer wants. Of course, it's a different matter if the code is insecure or something but I really don't care about the extremely fine implementation details.

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

#19

Post by gojomo »

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…

"Open source: the gift that keeps on taking."

(Earliest use I can find here – https://twitter.com/devbisme/status/1017520086096207874 – but perhaps goes back much further.)

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

#20

Post by ay »

c7DJTLrn wrote: post #6

I think many developers treat PRs as an opportunity to gatekeep. I'm not a very politically correct or emotional person but I think gatekeeping/nitpicking is extremely demotivating and it should be avoided wherever possible. When I review PRs, I'm looking at the big picture. I'm looking to see if it introduces security issues or diverges from standard practice. I don't care if there's a slightly better way which redu…

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 this is to be more proactive and discuss first and then get to coding. Oh, and be prepared you would need to code an approach different from what you wanted.

And there is absolutely no shame in forking the repo, doing the changes you could not get merged, and keeping it around for your own/your org use.

It is all about tradeoffs.

Post reply on HN