I feel the pull of perfectionism in my own Rust project [1]. Rust itself sets such a high standard of bending tradeoffs, trying to meet competing goals (and to some extent succeeding), that I feel like my own library project needs to meet that same standard of perfection. I fear I might have made more progress toward my actual goal by now if I had gone with C++.
Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
71–80 of 245 posts
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#72> 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…
Because you want to be able to make high quality contributions, you want to learn?
If you don't have that desire and can't take critical feedback then it's not really a contribution that the maintainers want to be attempted, so that's fine.
Nobody's saying the feedback is hostile or outright dismissive, and generally what I see (no experience with LKML specifically but I assume the same) isn't. It might get there if it's repeated, or the author shows no interest in improving just 'pls merge works for me' sort of thing - but by that point what's in it for the maintainers to be soft and encouraging, if there's no willingness or cooperation?
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#73Neither the PR, nor the linked issue, goes to any effort to explain what the work is and why it is needed. PRs should always have a carefully written intro, unless they are doing something totally trivial. For a new feature, the PR intro should explain the background and why the feature is justified, a high level overview of the code changes, and how correctness has been established. 30 minutes writing a PR is not much, especially if you've been working on something for more than one day. If your company doesn't have that culture, your company should change.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#74I 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?
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#75I 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…
It's a double-edged sword. Rust gives all the tools to make really performant software and tries to keep inefficient operations visible. But in many situations doing it the "proper" way requires a deep understanding of the type system and a lot of experience so you can tell the compiler what you're trying to do. Most things just aren't performance critical enough to warrant a day of experimentation, and many features…
I don't have any first-hand experience with this topic, but it seems reasonable that Rust has a special attraction for perfectionists. So many features to play with to get the most efficient, memory-safe etc. code...
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#76Earlier 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…
Because you want to be able to make high quality contributions, you want to learn? If you don't have that desire and can't take critical feedback then it's not really a contribution that the maintainers want to be attempted, so that's fine. Nobody's saying the feedback is hostile or outright dismissive, and generally what I see (no experience with LKML specifically but I assume the same) isn't. It might get there if…
> bug ridden garbage
This is what I was reacting to. Does this suggest that the feedback is likely to be constructive?
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#77> 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…
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 maintainers, both in reviewing the contribution and then later on maintaining it. If the contribution is good, it offsets those costs, but oftentimes it is not the case. Don't get me wrong, there are countless brilliant people out there who are doing great work more or less for free in the way of contributing. I'm also very grateful for good contributions. Those contributions are the exception though, not the norm.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#78> 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…
The fact is, most people can't write bug free code, that is also maintainable. It's a skill that takes years to hone. Even someone that is smart enough to understand all possible code paths and can prove it is bug free, doesn't automatically mean the code is written in a way that is easy to maintain.
Also, open source goes both ways. Anyone can submit, but maintainers can deny. Their project, their right.
Please remember, the bar has been set this high by successful projects.
One of the reasons Linux became the world's most used OS kernel was because of the high standard Linus maintained for his project. (Not saying I agree with his colorful word choices, but in my opinion most of the time he was 100% right about the PRs.)
That's why he calls himself benevolent dictator for life. The high standards must be maintained for the project to continue to be successful.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#79I 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 and move on to devote your precious time and energy to other things related to your code, which remains an enjoyable place to work. That looks like the story of that ligatures PR.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#80I 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]