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'