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