Live data from Hacker News

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

gist.github.com

161–170 of 245 posts

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

#161

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

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 judgmental about all sorts of stuff.

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

#162

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…

I agree with this as well. I use Alacritty all day, every day for work. It does exactly what I need and is very fast and stable.

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

#163

Off-topic: Someone mentions in the Github comments that Rust has "self-imploded". I get it's a joke, but have there been significant bad events in the last couple of weeks?

https://news.ycombinator.com/item?id=29306845 "Rust Moderation Team Resigns" ?

Which is not even remotely close to "Rust imploding", just in case people aren't clear about that.

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

#164

Earlier quoted context omitted.

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…

"Accepting" a pull request means merging it, and broken code should not be merged. By all means feel free to propose improvements to the PR, then merge it. And if achieving a reasonably well-defined standard of correctness (i.e. avoiding complete and utter breakage) is not feasible, the PR should be scaled back until it becomes so. Start with the minimum useful change, then expand on it.

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 with it

3. Fix and iterate it

4. Release.

The approach on some open source projects amount to:

1. Refuse to integrate code until every conceivable thing is thought out and dealt with. Burn through and push away tons of contributors in the process

2. Integrate code (or sometimes just give up and throw it away!)

3. Discover there were bugs in it anyway, because no code is perfect. Fix them.

4. Release

I would put money the releases put out by projects that spend years arguing to get PR's "correct" are not of any higher quality (by bug rate, etc) than the ones that accepted more experimental code and iterated it in the codebase. In fact, i'll put money they are worse.

One (of many) reasons is that the former process is one where people are expected to fix bugs and issues after integration, and that their job does not end when the code is integrated. This matches reality - bugs will be found, issues will be discovered, etc.

The latter process often makes people feel like once it's "ready", it's "ready", and it's done. That just doesn't end up true in practice unless it's a remarkably simple system. (or you have highly verifiable systems/process)

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

#165

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…

How many other non-apple apps “stick out like a sore thumb”?

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

#166
post #80
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…

[deleted]

[deleted]

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

#167
post #138

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…

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

I think this is well put.

If anyone suggests saying that someone or a group is only capable (for whatever reason) of producing 'bug ridden garbage' in any context, then I'd politely suggest that this isn't the best way to communicate the issue.

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

#168

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

I think I often see this disconnect, with developers on either one side or the other, and usually the distinguishing factor has to do with what their experiences have been. If you've ever maintained, like, anything - not even necessarily open source but even something at work (with users obviously) - for a significant period of time, long enough to see how a project evolves over time, you'd just... understand.

People without that experience can at times be a little too demanding when they don't get exactly what they want the first time. At times the may even act out, often in ways that are actually harmful, like trying to get managers involved to override something, writing negative stuff about you or your project online, or in general getting fairly hysterical and creating a fuss. When you try to help them they get super defensive, often before putting in the effort to understand what it is you even said.

So it's certainly the case that "bug ridden garbage" isn't optimal vernacular, but at the same, what I think can be worse is, as far as communication problems go, nitpicking project maintainer's communication whilst a.) not understanding that their underlying point remains actually true (I.e. "bug ridden garbage"), albeit not beautifully articulated and b.) not giving them the benefit of the doubt in terms of what their intent was.

Now imagine this, but literally all the time, all day, every day, etc... it can wear you down a little thin. Basically, when someone doesn't understand something, which is why the code needs to be reviewed in the first place, some tend to kind of lash out while latching onto something else they do know, e.g. I know that "bug ridden garbage" isn't a graceful way to talk, so I'll attack that.

Anyway, I'm probably not explaining this very well, and I think it's just something that people need to experience themselves. I've come to take people who are rough more as a compliment than anything, thinking, "this person thinks highly enough about me that they can just say what they really think, so I better not disappoint them by taking that trust and trashing it", obviously there are limitations, but this has helped me so much to learn from people smarter and more experienced than myself.

I'll just say one last thing. From what I've seen, the people who do tend to get defensive and kind of nitpicky about maintainer communication tend to not succeed when they become project leads themselves, and they usually just change jobs. O and obviously the maintainers who have the ability/experience and are blessed with grace, diplomacy, communication skills or however you want to call it, obviously tend to enjoy the most success.

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

#169
post #92

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…

>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.

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

#170

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…

If it's "not perfect" but still logically correct and useful to the project, then by all means feel free to merge and refactor it later. But broken code that will introduce bugs/defects should not be merged.
Post reply on HN