Live data from Hacker News

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

gist.github.com

61–70 of 245 posts

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

#61
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

Yes, Kitty is too resource hungry for my taste as well. And the Alacritty devs outright refuse ligature support because all existing implementations are too low quality in their opinion.

So now I'm just using st with a ligature patch. Not perfect and rather slow when dumping a lot of text to stdout, but it's otherwise snappy and does everything I need.

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

#63

> 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 contributions or whether maintainers should accept them. Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere.

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

#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 of reviewing and I really like it.

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

#66
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?

My favorite way to use tmux or et is with tabs in iTerm2.

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

#68
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

for some reason wezterm is very slow for me. I can see how neovim window is being drawn...

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

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

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 don't really need generics and all the syntax overhead that comes with them.

When you combine that with perfectionists it can probably get annoying. It's sad this is common enough to drive people away, because I think Rust is a great language and using it "well enough" is the first step to learning how to do it better. Imho it's not realistic to expect everyone to really understand all aspects of traits, lifetimes etc. because those can get really tricky really quick and not every behaviour of the compiler is consistent in those areas.

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

#70

> 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 don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time.

I've seen some truly impressive contributions over the years and the common element that stands out isn't the authors' skills or experience (even those can't always help you) but _patience_. Be kind, expect to be treated kindly, and just take your time. Breathe. If you receive feedback that bothers you, put it away. Sit on it and come back to in a week, or month, or whatever. Or walk away -- it's your choice. But the ones who are patient almost always succeed.

And if it's the maintainers who lack patience, or they've dropped off the face of the earth -- just fork and move on with your life. That's the spirit of the whole thing, after all.

Post reply on HN