In JSON the de facto standard for datetime is (because of JavaScript) very much the Unix msec timestamp (which is always in UTC) so while it's not hardcoded in spec you basically need to be an idiot not to do it like that, and removes one huge headache of XML dates which is timezones.
I don’t think that I’ve ever seen msec timestamps passed around because JSON numbers are floats, which means that there’s a limit to the precision available (which is to imply as well that currency amounts should be passed as decimal strings in JSON for safety as well).
Suggesting that msec timestamps resolves timezone issues is naïve at best, because anytime you are passing something that refers to a real time (that is, it is significant to humans) rather than an instant time (that is, it is something like an event log timestamp), you are dealing with time in a particular place, which has human impact — cultural, legal, linguistic.
Passing around timestamps as RFC3339 UTC strings with timezone names and offsets (much like one should be doing in databases) is what would be recommended for real (human) times.
Few years back, Convey[1] has apparently outran HAProxy in an alleged benchmark by the author[2]. That's a one man project (now abandoned, sadly) outrunning a decade old product built by an enterprise company AND a big community AND spearheaded and designed by a data structure genius. Granted, only in one of many tricks HAProxy can pull, but still. Not a database but indeed a concurrent world-facing RealWork software. If true (didn't actually check myself), I'd say it fits your bill.
Personally, I read that as "can be as fast as, but without you having to be Willy Tarreau level genius" which is all I need.
It's easier/more-intuitive to do a lot of things in C++, but safe, high performing C++ is certainly harder than safe, high performing Rust for huge swaths of use-cases. Also, as has been mentioned, its type system that benefitted from the PL research since the 80s also allows for nicer expression of business logic. In particular, this means that in Rust, unlike C, Go, or even C++ in great part, you are not writing in the same low-level intricate language at every level of your stack i.e. it can be a nicer high-level experience the higher you go if you designed your lower tiers well.
And that last thing to me is the biggest advantage it has over the competition.
Off course, there is also the fact that juggling dependencies in a non-trivial C++ project was a nightmare until recently with vcpkg and it's manifest mode and that will take probably another decade to become commonplace in the ecosystem (if ever).
HackerNews is really a bubble sometimes. I don't get who the "many people" that "got used to macOS" are.
Apple had fiery fest of sales in Q4 2021, outsold all Wintel manufacturers, let alone Chromebooks. And after that, guess what, they now have 8% of desktop/laptop market share, instead of 6% they used to have. You can guess who covers most of the other 90+ percent.
So XFCe == GNOME and LXDE is GNOME or KDE, depending on which version we're talking about?
UI toolkit doesn't equal a desktop environment. There is tons of stuff in the GNOME ecosystem (some of which it will make a lot of sense for System76 to reuse, no doubt) that can be entirely ignored when you're using GTK to, essentially, draw your UI widgets for you.
I still collect things I care about, I have tons of FLACs (some ripped from my CDs, some bought online) from artists that are meaningful to me and whose music is significant in my view.
I'm still grateful for Youtube and Deezer (I hate Spotify's UX so I'm never there) for providing me access to music I wouldn't necessarily collect, but I'm now also not at will of some radio DJ when I want that kind of ephemeral music in my life.
Open Cycling Maps combines OSM data with open source topo data and works really well. The gold standard for digital hiker is a gpx track made by experienced mountaineer, on top of OCM.
Between that, satellite imagery and offline capabilities of a modern phone and a hiking app that supports these formats you're all set.
The reason that you should have a topo map and compass, and know how to use them is that your battery cannot be expected to serve you throughout a multi-day hiking/camping trip.
It is also a frustrating experience to endure reloads on every click if what the user is using feels like a web application and you're essentially placing that burden of reducing the interaction roundtrip time on your infrastructure which gets expensive really really fast.
Most web-thingies are neither 100% plain websites nor 100% plain webapps, most are in the middle, some are heavily leaning on one side or the other.
