Rust maintainer perfectionism

rust-maintainer-perfectionism.md

Rust maintainer perfectionism, or, the tragedy of Alacritty

I did not submit this to Hacker News and did not intend that this post would have high circulation but have no real problem with it being there or with it having such. I have more recent comments below. This post is from January 2020 and predates the Modular Font Editor K (MFEK) project.

I have not worked on Rust projects in quite a while, and don't know if I ever will again. I feel many crate maintainers are way too perfectionist, for example, despite all the developer hours that went into this PR, it took the effort within years to be (halfway) merged.

There's always a reason not to merge, isn't there? It would be better done with a new nightly language feature, or the function signature should have a where clause, or the documentation is not perfect. There's always a new nit to pick in the world of Rust crates, it seems. There's always a new pseudo-problem to tackle. Eventually, developers give up, which suits these maintainers just fine: after all, their baby goes on unchanged, and should they find the feature necessary, or the bug bothersome, they can fix it much better than any outside contributor. (Or so they tell themselves.)

So, here we are in 2020, and nix#864 remains unmerged. Fred, you say, you overreact. It's just nix, not a larger problem in Rust crates. Or, worse, you're the problem. No.

Let's look at another project, alacritty. Don't we all remember it? It was supposed to bring Rust to the mainstream Linux desktop. It was supposed to be the new standard tty. It was supposed to be a revolution, shaking the foundations of the Earth! And, for a time, it was: Alacritty is a wonderful little program. But perfectionism came too for Alacritty. @kovidgoyal's kitty launched around the same time and had similar goals: modern OpenGL terminal, high performance.

So what stopped the revolution? Simple: Perfectionism. Reading through the Alacritty pinned issues is like reading through a book of sorrows. So many reasons not to merge. So many reasons we can't do it. And if the code is not perfect, God forbid we make it optional. Why even try, if it will not be perfect? I commented on the Alacritty ligature issue, and the theme of my comment is now a regular one on their tracker: just use Kitty. Even its maintainer says, "If you feel like the goals of Kitty are more aligned with your personal preferences, why not support Kitty, it's a great terminal emulator."

Indeed. So while Alacritty celebrates getting scrollback, Kitty is no longer a toy TTY: it is ready for serious use. And that's why I decided to take the time to contribute to it, adding, pending PR acceptance, background images. (A similar Alacritty issue exists, and it looks just how you imagine: moaning about how hard the problem is and how much we'd need to ruin our perfect code to support it. Quoth @i30817, "depressingly conservative." Depressingly!)

(Note: This blog post reflects my opinions only and not those of anyone else—not any other developer mentioned here, but mine alone.)

Well. Kitty takes a noticeable amount of ms to open. Alacritty is virtually instant. You like images and ligatures? Good. I like my terminal emulator to open fast. I have alacritty, you have kitty. What's your problem? That alacritty community does not agree with your personal views of the world? Grow up.

I'd hardly call time to start material because kitty is capable of spawning multiple windows in one process. (Ctrl+Shift+N.) If you use a tiling wm you should tell kitty to launch itself as kitty -1. I've patched kitty quite a few times and am willing to review any issue @kovidgoyal hasn't had time to. All the best.

I do use a tilling wm, and I'm aware of the -1 option. In fact, I still use kitty sporadically for certain things and it is bound to an alternate shortcut. But the startup time (and by that I mean the time between hit the shortcut and the time all graphics are stabilized and window is usable) is very noticeable for me. I also don't find it fair to compare launching a new process like Alacritty does (and I have a bazillion reasons to want a new process per terminal) vs spawning a new window.

It's fine. Kitty is not as fast as Alacritty and probably never will be. And Alacritty will probably never have all the shiny bells and whistles Kitty has. They're both very fine and capable terminal emulators. Why do we have to always end up in these stupid tribal wars, and end up looking like clowns to normies?

edit: I realized I haven't replied to your offer for help to debug. Of course, if you need anything to help you improve kitty, let me know what logs/bench/whatever you need

Hello, my comment to you wasn't meant to tell you to start or stop using any particular software, as I find such discussions unhelpful and to be a waste of time as I'm sure you do. I was just commenting as a Kitty contributor, which you seem to have noticed in your edit. I use KDE so I have to admit I never noticed the slow start time, but that's because I tend to always have one instance so I'd only ever see Kitty start when I launch KDE, so, rarely, and I'd probably chalked the slowish start to the DE starting. The manual seems to lead me to believe that most of Kitty's start up time is due to initialization of the sprite cache (which is rather large, especially if you use a complex font). With that in mind, I wonder if you try to use a much simpler font if the time goes down? It does for me.

Also, I don't really care what I look like to a "normie", I mean obviously, furry avatar and all, lol.

If the font is the issue given my main area of contribution to open source is to font technology I have ideas for patches that could tackle the problem. If you want an idea of a font to test with, try clR8x8 https://github.com/ctrlcctrlv/clR8x8 and use it at a smallish size.

OK I've managed to reproduce this.

[fred@🍇葡萄🍇~]$ time env -u WAYLAND_DISPLAY alacritty -e echo

real	0m0.165s
user	0m0.143s
sys	0m0.049s
[fred@🍇葡萄🍇~]$ time kitty --instance-group debug9 echo
[332 01:13:15.006344] Ignoring invalid config line: url_excluded_characters

real	0m0.251s
user	0m0.180s
sys	0m0.078s

You might think it's unfair to compare kitty on Wayland to Alacritty on XWayland/X11. Sorry, but Alacritty isn't launching at all for me on kwin_wayland, so it's a bug workaround due to a broken application on Wayland (perhaps KWin is to blame, IDK).

Also, debug9 was a never before used instance name. I'm going to run some benchmarking, please try the font thing and let me know, I think this is solvable.

To discuss the unrelated Kitty issue I've opened kovidgoyal/kitty#4292. Let's move discussion on that there.

lol kovidgoyal/kitty#4292

Well, I'm sorry @ctrlcctrlv, but I'm not gonna be able to help you, even if I still wanted to :) he blocked me

As you can see we're really getting somewhere with this, so your trollish nature might bring about the changes you seek after all ;-)

I'm not trollish. I was genuinely trying to help and willing to provide details to a project I honestly don't give a fuck about. Calling me out of the blue an "Alacritty apologist"? I don't give a fuck about Alactritty either. They are terminal emulator. You guys are not saving us from cancer. I even gave you a security reason why I would launch terminals in several processes. I've read this tracker several times back in the days and noticed the blatant stupidity and arrogance of your maintainer in multiple issues. I was coming in peace, I'm not coming back anymore. Have a good life

Well that was a heated discussion

@primalmotion 無茶苦茶切れてて草
冷えてるか〜？Foo！

ハッカーニュス―のユーザーであるための要件は無茶苦茶切れてるよ。
常に、毎日に。カキコを切れちゃなきゃならないわ。