Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
1–10 of 245 posts
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#2And the honeymoon is over.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#3Ah! 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
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#4Ah! 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.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#5And the honeymoon is over.
Yeah theres so many issues popping out of the rust community and projects I didn't think that would happen. Guess I have a lot to learn
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#6I 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 reduces the number of branches - if I see it as worth changing I'll do it myself after the merge. I'm not looking for all the reasons why it can't be merged, I'm looking for the minimum changes needed to make it comply with the codebase's existing standards.
This post also highlights one of the reasons I fell out of love with Rust. There's too many ways to do things.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#7I understand the point of view of the author, but at the same time I appreciate how simple and not bloated Alacritty is, there is great software out there but terribly bloated with features that become useful only in edge cases.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#8A lot of their comments seem justified though and it looks like you were learning a lot from it as you mentioned it was your first rust merge.
Also a lot of the delay was because you didn't have time to work on it as you mentioned in 2019 :)
I'm not a developer but I read through the thread to see what it's about. But I think most comments were constructive criticism or just non blocking suggestions even.
Though code quality seems to be a higher goal than in most projects I know, that's kinda admirable too. I can imagine your side too though, it's frustrating to be working on something and not seeing it go forward.
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#9I 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 beyond the point I was trying to make), how I didn't know even basic CompSci (well, I do, I managed to get a degree and work in this field for nearly two decades, but I disgress)... it was a pretty harsh experience, and I am now much more conservative with talking about my Rust code publicly as a result!
Re: Rust maintainer perfectionism, or, the tragedy of Alacritty (2020)
#10I have also experienced this frustration and it has turned me away from projects before. There is always some reason to block a PR. However, I found that creating my own open source projects helped me sympathise with maintainers of popular projects. I think of it this way: Say you work at a company and there is a lot of work to do. The bar can be low for accepting PRs because it is assumed that the author will stick around to fix any issues they caused and you have to deliver so in it goes. However, a maintainer of an OS project first of all probably does not have the same problem you are trying to solve AND they may not trust that you will stick around to fix any problems your code may cause in the future. On the other hand they want you to contribute because this makes the project more popular and there is a chance that you will become a maintainer yourself. It's a balancing act.
This is why it is important for a channel of communication to be opened between all those interested in the project (a chat group) to grow rapport.