undefined | Better HN

0 pointsexceptione3y ago0 comments

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.

0 comments

int_19h3y ago

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).

exceptioneOP3y ago

«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.

int_19h3y ago

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++.

exceptioneOP3y ago

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.

xxs3y ago

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

steveklabnik3y ago

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

(Rust can also do in-line assembly…)

burntsushi3y ago

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

xxs3y ago

ugrep has full SSE/AVX support

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

burntsushi3y ago

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.

metaltyphoon3y ago

If I would have to guess it would be codecs.

burntsushi3y ago

What do codecs have to do with grep?

1 more reply

j / k navigate · click thread line to collapse

0 comments

int_19h3y ago

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.

exceptioneOP3y ago

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

int_19h3y ago

exceptioneOP3y ago

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.

xxs3y ago

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

steveklabnik3y ago

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

(Rust can also do in-line assembly…)

burntsushi3y ago

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

xxs3y ago

ugrep has full SSE/AVX support

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

burntsushi3y ago

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.

metaltyphoon3y ago

If I would have to guess it would be codecs.

burntsushi3y ago

What do codecs have to do with grep?

1 more reply

j / k navigate · click thread line to collapse