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.

First they have to decide what distribution actually matters for the desktop, out of hundreds that get forked for frivolous reasons.

And yes accessibility and localisation were already a thing in Windows 3.x, classical Mac OS, OS/2,...

See the hype about TUIs as if Turbo Vision, Clipper and ncurses never happened.

Once upon a time that was all many of us could reach for.

Which unfortunately most people avoid using, and until C++26 there is no at() for span.

The best is really to enable compiler specific hardening.

They do when using hardned runtimes configuration, which was compiler specific, and starting with C++26 is officially part of the standard.

It naturally doesn't cover C style programming in C++.

My first agent test was pointing it out to my toy compiler repo (L98) and ask to translate the AT&T Assembly files that gave me so much trouble to come up with (my head has Intel syntax burned into it), and translate it back to Intel syntax.

In a couple of seconds I had it back.

Didn't bother commiting the changes, because it works and was a toy compiler anyway.

Remember Axum or the reflection drama?

You're probably thinking of Actix and the unsafe/TechEmpower thing? I've never seen Axum involved in any notable drama.

Yeah that one.

Yeah; but that was 6 years ago - from way back in 2020. Was it really that traumatic for people?

That was part of Rust Evangelism Striking Force meme genesis.

And then we have the whole reflection drama with the author going back contributing to C and C++ ISO work.

Not even C/C++, only if vim and emacs are the only experience one has ever had.

See Visual C++ (with hot code reloading, incremental linking, AI integration, on the fly analysis), QtCreator, Clion (comparable with VS in many options), C++ Builder (with its RAD capabilities),....

Cargo is great as long as it is only Rust code and there is little need to interop with platform SDKs, then it is build.rs fun.

> Who is using native UI in 2026? GTK and QT don't feel great.

Game developers, Windows applications in .NET (possibly with some C++/COM modules)

The problem with native UIs is mostly a Year of Linux Desktop problem.

Let's set gaming development aside for a moment.

I believe when people talk about Rust UI, most people assume it's cross-platform. Developing an app just focused on Mac or Windows is a completely different problem. In fact, one could easily argue that you should never use Rust for those single platform apps.

Yes, because code review isn't common, it is at the same level as writing documentation, or unit tests in most companies.

Unless there is some DevOps freedom to at least put something like Sonar or clang tidy on the build pipeline breaking PR that don't play by the rules, and even then you cannot prevent everything via static analysis rules.

I think it's (mostly) sufficient to have a regex on git change-set for "new" "malloc" "calloc" keywords to cut most of such stuff if you have such a policy.

Documentation / UT are harder to define (what is good documentation, is UT covering everything?), but usage of manual memory handling can be spotted relatively easy automatically. There can be some exceptions for 3rd party libs interaction if it's absolutely necessary but detecting such occurrences and keeping track of them is relatively easy.

See, already there you missed all the C language constructs that C++ is copy-paste compatible with, and should only be used inside unsafe code blocks.

Which in C++ good practices means type safe abstractions not exposing any kind of C style strings, arrays, casts, pointer arithmetic,....

Unfortunely still relatively rare, some of us when we were the C++ Striking Force in the 1990's Usenet flamewars already advocated for such practices, most of them already possible with C++ARM, no need for modern, post-modern, rococo, baroque or whatever C++ style is going on with C++26 now.

Zig would be an interesting contender back in the 1990's between Object Pascal and Modula-2, nowadays we know better.

For me while Go is definitly better than Oberon(-2), and Oberon-07, some of its design decisions are kind of meh, still I will advocate for it in certain contexts, see TinyGo and TamaGo efforts.

As old ML fanboy, you can find such tendencies on plenty of languages not only OCaml. :)

I see Rust as a great way to have made affine types more mainstream, however I rather see the mix of automatic resource management + strong type systmems as a better way forward.

Which is even being acknowledged by Rust's steering group, see Roadmap 2026 proposals.