You cannot even get it with Rust/WinRT straight out of Redmond, let alone having hopes to get it on Linux.

C++/WinRT tooling is a shadow of C++/CX capabilities (which feels like Microsoft's C++ Builder), and while the same folks are having fun with Rust/WinRT, its tooling is even worse.

I doubt that in five years it will be any close to what C++/CX was already doing in 2015.

Specially since they outsource any graphic tooling responsabilities to the DevDiv folks.

That's sad. I would love to tinker with UI programming on Linux, but it seems like to get anything decent you will have to use QT, which brings C++ as a requirement.

You can have a look at its issues,

https://github.com/microsoft/windows-rs

Note the lack of of safe wrappers for Windows APIs, and still no good way to create the Windows Runtime objects necessary to interoperate with XAML.

Also the basic examples with very little UI code on what is supposed to be a projection for a Windows UI framework.

Thanks. I did not mean XAML literally though, something like that would be super nice for Linux. The project you linked brings Windows RT as a requirement. But just something with the richness of QT + Rust on Linux would be welcome. I am hearing the rust bindings for QT are just a pain and incomplete. I was hoping for Rust to really offer an alternative for C++ here.

Well, there is Slint in that case, from former Qt devs, but it is still pretty much early days.

https://slint-ui.com/

Check their online demos.

Thank you, still early indeed but the project looks promising. I am really hoping for the Return of the Desktop in which episode Rust defeats C++ and we all have a sane, safe, free and memory abiding computing experience.

UI is a poor fit for Rust, IMO, because the natural way to model UI widget hierarchies is rather painful with ownership tracking in the picture.

But I don't see why that precludes Rust from being a good choice in other applications, CLI in particular.

Well, isn´t that a bit damning though? I am not an expert on Rust, so please enlighten me. If it is meant to replace C++, I would expect it to dethrone on the areas where it is king. I am looking at a crap ton of programs with an UI. Your IDE, your text editor, your spreadsheet program, your graphics editor, etc. Most of the modern programs just give up and ship as a full blown bloated memory eating web browser.

There is a gap between the nineties and now, and it is still void.

If you have to constrain it to CLI apps the average developer here on HN needs to write, I don´t see a reason to use such a complex beast as Rust. If you mean operating systems, I can see a spot for Rust. Also database systems or a web server implementation. But that is fairly niche.

For userland cli-apps I am not sure if the added complexity pays of in terms of sufficient performance gains in practice. If you want to write a new implementation of grep, sure. But how niche is that?

So in those cases where you need both type strictness (which I agree should be the default requirement) and cannot have an automatic garbage collector, I can see the value of Rust.

But for what audience is an automatic GC really a problem? Personally I would use Haskell, Java, F# for CLI-apps, but I know there are tons of other options there.

For CLI apps, performance may be important, and Rust offers a performance profile similar to C++. This is exactly the niche where relying on an automatic GC may be undesirable.

But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC. It kinda makes sense if you only focus on management of memory as a resource, but it ignores the whole race condition angle (which very much still exists in GC'd languages like Go or Java).

«But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC.»

Agree, that is not what I meant. Rust provides type safety and allows you to without a GC, all while offering top speed. Being able to do without a GC is somewhat of a niche requirement I think. In those cases it is an requirement, Rust would be a top choice.

My point is: there are tons of GUI applications written in C++. And to this day there are still new projects that pick C++ because it needs a GUI. I consider that a bad thing for Rust. Thinking Rust should be at the CLI-apps competition is just a way to avoid C++. It is the wrong contest, and I am not sure if Rust is even able to win that contest because what Rust has to offer (no GC) isn´t of interest for most CLI apps. I think cli apps like kubectl would not be hurt by being GC'ed.

I think that the Rust leadership should identify that GUI is the first city they need to liberate from C++ if they ever dream to replace C++. I just learned some original work has started by various projects, so I keep my fingers crossed.

The question, rather, is why one would want to use C++ rather than something higher-level (e.g. C#, Java, Swift) for a GUI app in 2022. We're long past the point where performance benefits were worth writing the whole thing that way. Most apps can get away without anything C-like at all, and for the few that need that perf boost, it's easier to implement the corresponding part as a C++ library called from higher-level GUI code. In such an architecture, Rust can transparently replace C++.

I see your point, but that also means data marshalling between the higher level language and the rust components. Also, I think GUI is a place where speed plays a significant role. It is no wonder that most GUI's are written in C/C++.

Unless you mean that the lower level GUI code should be rewritten in Rust, so that other languages can provide a higher level interface on top of that. That might indeed sort of work. But the vast amount of work is going to be in Rust. And you still pay some penalty, depending on the mismatch of the higher level language and rust. You will need to have a frictionless integration as between C# and WinForms.

The hard work is on that lower level. A simple text input control takes a lot of engineering. You will still end up with something like QT in Rust.

grep inner loops are coded straight in Assembly. So Rust would be a poor fit.

Yet ripgrep is extremely fast, often faster than grep. Practice beats theory.

(Rust can also do in-line assembly…)

Can you link to the source of any widely deployed grep whose "inner loop" is coded in Assembly?

ugrep has full SSE/AVX support

https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8c...

So does ripgrep... Which is written in Rust. So how exactly is Rust a poor fit?

And that isn't Assembly.

So I guess what you said earlier, "grep inner loops are coded straight in Assembly," was a misrepresentation. And that "Rust was a poor fit" is just empirically wrong.

If I would have to guess it would be codecs.

What do codecs have to do with grep?

grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv).

However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.

Those are locales. I've never heard them referred to as "codecs."

In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)

"en_US.UTF-8" is a locale. The "UTF-8" part is the encoding of that locale. Codec would be whatever piece of code parses the encoding.

>in the kernel that gets executed due to some syscall from grep

That won't be considered 'inner loop'