I thought so too, but for a while I had 2 144Hz monitors on my Mac Pro[1] and very much noticed it in the UI, window dragging was smoother, browser scrolling too, absolutely noticeable.
[1] Then Apple released the Pro Display and Big Sur and people wondered "how does the math work for a 6K display and bandwidth?" The answer, they completely fucking broke DP 1.4. Hundreds of complaints, different monitors, different GPUs, all broke by Big Sur to this day just so Apple could make their 6K display work.
My screens could do 4K HDR10 @ 144 Hz. After Big Sur? SDR @ 95 Hz, HDR @ 60Hz. Ironically I got better results telling my monitors to only advertise DP 1.2 support, then it was SDR@120, HDR@95Hz.
Studiously ignored by Apple because they broke the standard to eke out more bandwidth.
From my perspective, it's not useful to dwell on the fact that LLMs are often confidently wrong, or didn't nail a particular niche or edge-case question the first time, and discount the entire model class. That's expecting too much. Of course LLMs constantly don't help solve a given problem. The same is true for any other problem-solving approach.
The useful comparison is between how one would try to solve a problem before versus after the availability of LLM-powered tools. And in my experience, these tools represent a very effective alternative approach to sifting through docs or googling manually quote-enclosed phrases with site:stackoverflow.com that improves my ability to solve problems I care about.
Simplicity is feature on its own, you can't please everyone and you have other choices. Considering feature parity - I used small window managers in the past: Fvwm, Fluxbox, Pekwm... what made me eventually stick with Gnome was that It made things like Wifi, printing, mounting disk... seamless - on par with Windows. That is a lot more important for most users than customization, which can be overwhelming in environment like KDE (I haven't used it in years).
I agree, simplicity is cool. That is why I love to support platforms that are simple to support. Say, if you have a piece of software that has it’s main entrypoint be a status icon, it suddenly becomes incredibly difficult to support gnome, since different distros will ship with different versions of gnome, which support different versions of status icon plugins, which work differently and sometimes they dont even have the plugins in the repo. Suddenly a feature that just works turns into a 3 page ordeal in the user manual do deduce what plugin must they install where to make our app work.
If it works everywhere except Gnome, requiring a custom solution on Gnome alone, it's definitely Gnome's fault. Gnome people have this weird ego thing where they expect the world to conform to them, even developers who are only including Linux support as a courteous afterthought to users. Anything Gnome does in a unique way adds friction for these developers, to the detriment of all Linux users.
I don't think UX is controversial, if you look at it from the perspective of average person. I was annoyed time to time by changes in Gnome UI. But I would not say I find KDE, XFce, Windows 11, Mac... more productive. I switched my old man from Windows to Gnome and had zero complains (which is rare). Having Gnome default makes sense as switching will not be a problem for advanced users. I personally don't have reason to switch.
There are a lot of third-party Linux apps built with GTK4/Libadwaita. If you just to to https://flathub.org and click on random apps a lot of them will use GTK.
Interaction between lifetimes in REPL would probably diminish any advantages REPL has to offer. REPL is easy to do in GC languages, trade off Rust made by choosing not to use GC. Best next thing you can use are tests which are part of Rust's tooling.