That's an "if you have to ask, it's not for you" question. Also, the noise these things make... You better have a separate garage. The constraints of a data center are really far from those of a homelab.

Rust compilation is actually very fast if you keep things Java-esque : No macros, no monomorphization (every Trait dyn). Obviously most the ecosystem isn't built that way, leaning more on the metaprogramming style because the language makes it so convenient.

Every community has these assholes. In my experience, the Rust user base is nothing but polite, understanding and pragmatic. There's no smugness, explicit or implied. The Rust lore is just a joke that's getting less funny every day someone takes it seriously.

I feel like it's far easier to find more zealously anti-Rust people than zealously pro-Rust people - hating Rust has almost turned into a meme.

They are people of very similar mentality, with opposing sensibilities.

The rest navigate quietly, bobbing in the rippling wakes of their passionate fighting.

Technically, I prefer Rust but I understand people who find Go better suited for their work. For example, devops is mostly Go nowadays and that makes more sense than Rust (or Python).

But I've never, ever seen toxic behavior from the Go community. For Rust, it's the norm, sadly.

Frankly, I see _a lot_ more uninformed attacks on Rust than actual Rust evangelism / snobbery. And most of these anti-Rust comments reek of personal insecurities and low-effort trolling. Like saying that Java is slow. It's getting old real quick.

We had Delphi and VB thirty years ago and the native UIs were pretty good. The web brought a massive regression in UI programming, functionality and usability that we generally haven't recovered from yet. Not every app can be a web site.

Sure. It was a simpler time.

Web didn't make massive regression in UI, it made minimum feature set huge.

So simple that layout managers were already a thing, even if Electron kiddies have no idea about them in native UIs.

By the 2000's doing pixel perfect native UI was a sign of being lazy to learn UI best practices.

Say what you want but for modern UI localization and accessibility are part of minimum feature set. Those two massively increase complexity (UTF8, IME, Braile, Text to speech, etc.)

The big issue I'm talking about is cross OS UI Toolkit. Great your UI supports IME on Windows and Mac. Now do that for Linux, BSD, etc.

I'm talking about accessibility and localization as part of a GUI toolkit.

Take localization. Any doofus with CSV and regex can localize a binary. How do you localize dynamic things like "Hi (Sir) PJMLP, you have (0 unread messages)"?[1]

In JS I can always Intl.PluralRules. Where are my Plural rules in say C#'s Avalonia (or whatever GUI is hot in C# these days, I can't keep track)?

The issue isn't a checklist; it's a quality of availability [2]. The complexity there is essential, because languages are complex beasts, and mitigations for disability are getting better and hence more complex[2].

[1] Why is localizing this a problem? Some languages are language neutral, some have honorific speech, which changes other words, and some have different ways of counting (Hello Welsh. Nice that you have ordinals for zero, one, two, few, many, and more), some have genders, some don't, some have but don't use it in some cases, ad infinitum.

[2] There is a huge Mariana Trench in the quality of accessibility for software that offers a magnifying glass and software that offers text-to-speech.

And I am talking that was already available in 2000's.

Do I have to link to digital copies of documentation to make my point?

Sure. Show me how Windows 3.* supported Unicode, i18n (internationalisation), l10n (localisation), a11y (accessibility), with special focus on CLDR plural rules.

Which will be interesting since Unicode 1.0 came around 1991. And CLDR in 2003. And Windows 3.x came in 1990.

I'm not saying it is impossible, just highly unlikely MSFT implemented those as early in 3.x. They could have taken part in those early efforts.

If you are so keen in Windows 3.x, remember before standards each OS did its own thing, and I can gladly show you the proprietary APIs used by Windows 3.x.

I imagine you never coded for it.

I'm keen on you explaining this part:

     > And yes accessibility and localisation were already a thing in _Windows 3.x_, Mac, OS/2

(emphasis mine)

Because it's the one I used of the things listed, and from my memories, its accessibility was extremely lackluster.

I don't care about API as much as you explaining what its a10n features were.

None of the things you mention would have been impossible to integrate in native GUI. They're platform features.

For someone using a GUI toolkit, there is a massive difference between "invent and integrate your own" and "it comes pre-installed".

I'm saying the reason modern cross platform GUIs are hard is that the developer and user preferences have changed. Developers want GUIs that come with many bells and whistles.

This raises the bar for minimal implementation from - "it will take one guy two weeks to implement" to "it will take a huge group decades of effort to implement."

And that's JUST the implementation. At any point, you also face an adoption cliff. Sure, your super layout engine (SLE) might automatically layout stuff, but Josh here doesn't know SLE, he knows CSS.

Yeah but whatever the browser provides, the OS can also provide. You don't have to reinvent a browser when you code outside of it. Anyway, this conversation had slipped out of the window. Web app UI programming tools still suck compared to what we had 25 years ago and say what you will, there's NO good reason for that.

Which OS? This is talk about cross-platform GUI toolkit.

My point was, "Why X language sucks at cross-platform GUI" is because X isn't JavaScript or TypeScript, and it's not backed by the huge corpo that is Google.

> Web app UI programming tools still suck compared to what we had 25 years ago

Funny. I can think of few examples, namely Flash, Dreamweaver, and Delphi, but that's more rose-tinted glasses than any objective metric. They all did a few things better than the modern web but failed in so many other ways.

Since when are browsers themselves built in JavaScript? Mainstream, fast ones?

Clarification - in the past when I've written high performance data tools in JS, it was almost entirely to support the use case of needing it to run in a browser. Otherwise, there are indeed more suitable environments available.

To your question, I was about to point out Firefox[1], but realized you clarified 'mainstream'[2]...

[1] https://briangrinstead.com/blog/firefox-webcomponents

[2] https://gs.statcounter.com/browser-market-share

I've been thinking about using an OpenAPI schema to describe cli tools. It would probably need extensions to describe stdin/stout and other things that don't happen in REST.

Have you seen Stainless's CLI generator?

https://www.stainless.com/blog/stainless-cli-generator-your-...

Command economies break too. Capitalism has occasional fires like a forest. This is good. It allows things to shake out. New growth comes from the destruction. Command economies don't. They just continue to grow weeds and tall trees until everything is choked. Then they wonder why everything is garbage.

The US is moving to a fascist economy. That is a form of command economy. For example the FDA is controlled by big pharma.

Capitalism with the ultra-wealthy is functionally the same as a command economy.

Little known fact, dragonglass is an excellent semiconductor

Gentoo's source based approach was always destined to be less popular than a precompiled distro. Compile times & customization options select for a certain clientele.

I think the reference was to Gentoo's wiki, which was indeed hacked and lost data iirc.

But yes, comparing distros themselves, Gentoo will not out compete streamlined and prepackaged distros in the broader adoption metrics.

The wikis themselves are largely distro agnostic and exceptionally useful for everyone on Linux though.

All my machines still run Gentoo (I have used it for over 25 years). I just love the package manager. It has become much more low friction with the binary packages and gentoo-kernel(-bin). I regularly visit both the Gentoo and Arch documentation. They even cross reference each other and both are a great resource.