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

181–190 of 245 posts

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

#181

Post by eminence32 »

neilalexander wrote: post #94
antihero wrote: post #51

Ha, trying to get Alacritty to have a native-feel icon for macOS which had basically zero drawbacks and most other applications do was met with a straight up NOPE. Not up for debate, people supplied the assets and I even made a PR, nope, closed. Even though it was in a directory full of platform specific stuff (Alacritty.app resources), it was decided that it couldn't differ from the other icons, so Alacritty has to…

This is frustrating because it is a change that has no other impact aside from making your users happier. The justification for not merging that is nonsense.

You don't have to agree with the justification, but calling it "nonsense" seems a bit unfair. The github threads are a bit long and with several different points made, but my reading of the bottom line is: "this is not the official icon, it should not be in tree"

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

#182

Post by jasode »

stormbrew wrote: post #169
jasode wrote: post #92

Earlier quoted context omitted.

>Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? [...] Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere. I think you missed the gp's point of bringing up the example from the long history of Linux kernel contributions. It's a counterexample to your intuition that people won't attempt to contribute if there's a "hostile atmosphere" (s…

.. Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through and it would still seem like there were no barriers. This is just survivorship bias.

>Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through

Your comparison is flawed because you're leaving out the fact that the Torvald's Linux kernel was also a tiny niche project in 1991 and that atmosphere of harsh critique has been there from the beginning.

And yet programmers kept contributing code to Torvald's small project in the 1990s and that evidence of behavior contradicts the gp's rhetorical question of: "Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?"

Linux wasn't on a million devices in 1990s so mentioning that later fact is not relevant to its survival characteristics.

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

#183

Post by franee »

antihero wrote: post #53
hiyer wrote: post #14

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

Do you need tabs still if you use tmux by default?

Just moved to kitty from iterm2 a few weeks ago.

Started with alacritty, but without tab support, was a deal-breaker for me.

I use tabs in kitty with tmux on each tab. Each tab is a context in my environment (dev/services/ansible/terraform/etc).

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

#184

Post by bluesnowmonkey »

nixpulvis wrote: post #125
DoubleFree wrote: post #65

This reminds me of a blog post from Aleksey Kladov: https://matklad.github.io/2021/01/03/two-kinds-of-code-revie... They state that reviews are not only meant to ensure good code, but also good coders. That means mentoring, but also merging the code if it's not perfect. Then, afterwards, when touching the affected part of the code again, cc the original author in a fixup PR. I have first-hand experience with this way…

Why not simply have the discussion in the review itself? Must we merge everything, just so people feel empowered? It's chaos to have to constantly revert and/or refactor everything. People should be empowered not by the merge, but by the progress. They key, from what I've seen, is to facilitate useful conversation. Keep comments relevant and people will learn. Avoid politicking, while still providing evidence for you…

> Must we merge everything, just so people feel empowered?

Sort of, yes. People develop confidence and expertise from repeated success at accomplishing things. Success creates confidence creates more success. You have to give people room to get that flywheel spinning for themselves.

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

#185

Post by Etheryte »

DannyBee wrote: post #134
Etheryte wrote: post #77

Earlier quoted context omitted.

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

My personal and very subjective opinion is that it's not my hill to die on. The majority of most things is not good, books, music, business plans, you name it. Open source contributions are the same — and that's okay. Much like I don't have a problem with people who write books I personally don't like, I don't take issue with people whose contributions don't align with what I think is good. I try to focus my energy on the ones that I find good, or at least the ones that look like they might end up being good. To perhaps put the same idea another way, if someone wants to put in the effort for making a change, it's their choice to do so. It is also their choice whether they take the time to do it well. If they didn't want to put in the work, it doesn't bother me, it's their time.

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

#186

Post by DannyBee »

zozbot234 wrote: post #177
DannyBee wrote: post #164

Earlier quoted context omitted.

Broken is a very loaded word. So i don't agree with this as written. If by broken you mean "does not compile or pass tests", then fine, sure. If by broken you mean "there are likely some hard issues in there", then no, i don't agree. I've watched plenty of really good software where the dev process amounts to: 1. Integrate code that is more experimental into the development trunk 2. Let people discover what is wrong…

> 1. Integrate code that is more experimental into the development trunk > 2. Let people discover what is wrong with it > 3. Fix and iterate it This kind of experimentation can be done on a separate branch. There's no need to involve whoever maintains the "main" development branch until the code is reasonably OK for release. In some cases, it can be acceptable to merge code that's clearly marked as experimental into…

Yeah, that's the party line for sure, but the end effectiveness of waiting until "it's okay for release" is low. You will never reach that point. Most experimental branches basically see no use outside of who is developing them.

So a lot of time you are only really getting them to the point they pass existing tests, and maybe whatever additional testing the person writing the code is doing. As a result it's really rare that code got enough testing on that branch that it was "ready for release" when it was integrated. Show me software done this way, and i'll show you software released with lots of bugs and point releases :)

One of these development processes admits that's true and integrates it at some earlier point and accepts it will take more work despite that.

I'm also not sure what "no need to involve whoever maintains the main branch" means. Software development is a team sport. If you don't want it to be, don't accept contributions (no judgement, i'm serious).

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

#187

Post by epolanski »

mgaunard wrote: post #44

A project owner has the final say into what goes into his project. Don't like it? Just make your own project. Why is the Rust community so full of entitled drama queens?

It's not just the Rust community, it feels like the entire OSS community cannot grasp that you can at any point fork and have your own version.

That's the biggest freedom we're given, expecting that any of our ideas or features should make it into a main release is both delusional and arrogant.

On a more general note, I believe more and more software should be modular and allow for extensibility. GNU and the FSF are good examples of writing very complex but composable software.

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

#188

Post by carlmr »

zozbot234 wrote: post #161
ghusbands wrote: post #131

Earlier quoted context omitted.

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 Far from it. In fact, the best thing about a correctness-oriented language like Rust is that you can immediately tell when stuff does not compute (the compiler will error out with a useful diagnostic, or else it will be in a small 'unsafe' block with easy to check safety conditions). Which makes it way easier to be less judgm…

This really describes quite well why Rust is such a joyful language to work in. You might still write garbage, but the compiler constrains the types of garbage you can write to a much smaller subset.

Whenever people say that a skillful programmer can write well-working C++, I don't disagree, but in my experience it continues to fail on projects with more people involved.

If your project has size N=1, and you're skillful it's not an issue, if you have N=2 or N=3, you might still be able to review everything and find very competent contributors.

But for bigger N, at some point you'll have average or below average skilled contributors in the project, you won't be able to review all contributions.

A strongly typed language, strict compiler, standard formatter, and standard linter however can scale in this way.

Rust offers all of these.

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

#189

Post by purple_turtle »

couchand wrote: post #105
skrebbel wrote: post #87

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…

I've found Rust programmers to be eminently pragmatic. The economics of bugs have been clear for decades: it is orders of magnitude more expensive to find and fix bugs after they've been shipped.

And, additionally, if someone is unwilling to fix known issues in PR - then they will definitely not fix bugs in it after it become merged.

So for maintainers merging PRs with known issue is basically promising to fix everything not finished.

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

#190

Post by ChrisMarshallNY »

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…

There's a chap named Linus, who is rather well-known for being a tough PR reviewer...

I feel that if we are talking a fundamental toolbox, like a language, standard library, or kernel, then being a perfectionist is pretty much required.

For myself, I agree that harsh language isn't particularly helpful, but I have extremely high personal standards. I seldom project them onto others, but if anyone wants to play in my sandbox, then they play by my rules.

Post reply on HN