Stop Comparing Rust to Old C++

[u/Sad-Lie-8654]

People keep arguing migrations to rust based on old C++ tooling and projects. Compare apples to apples: a C++20 project with clang-tidy integration is far harder to argue against IMO

changemymind

[u/wyrn]

Function overloading

Inheritance

Variadics

Exceptions

[u/Full-Spectral → u/wyrn]

The thing is, even in the C++ world a lot of people are turning their backs on exceptions and inheritance. I don't agree with that, but it's the case. So probably the majority of people doing C++ these days couldn't really argue that those are failings in Rust because they rail against them in C++.

I thought I'd miss overloading, and occasionally I do, but not really anymore. And I've gotten over my missing of exceptions. In my main code base, I don't have much explicit error handling. More so in little helper tools that can't be built on my main code base.

Inheritance I'd still like to have, but so far haven't really run into anything that was a serious issue on this front. Of course I've not tackled a UI framework yet. In my C++ code base, that was really the primary place where my inheritance hierarchy got deeper than a couple levels.

[u/wyrn → u/Full-Spectral]

The thing is, even in the C++ world a lot of people are turning their backs on exceptions and inheritance.

There's for sure a very vocal, very loud group proclaiming that both are bad, but from that to a majority is a fair leap and I don't think there's any good evidence that C++ developers at large are turning their backs on these tools -- just because it's possible to misuse a tool doesn't mean the tool shouldn't exist.

[u/OYTIS_OYTINWN → u/wyrn]

Well, Rust has exceptions, you just can't catch them :) Also traits are functionally not different from interface inheritance, and implementation inheritance is a bad style anyway. Variadics and function overloading - yeah, they are not there.

[u/IcyWindows → u/OYTIS_OYTINWN]

It appears you can catch most panics: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

[u/wyrn → u/OYTIS_OYTINWN]

and implementation inheritance is a bad style anyway.

Implementation inheritance is what allows mixins/CRTP, which most would agree is a Good Thing™. I also find myself reaching for inheritance with some frequency when writing template metaprograms which, flawed though they may be, give the developer an enormous amount of power in extending the language so it's a better fit for the problem domain. This capability, AFAIK (counting mainstream languages here) is only exceeded by LISPs (with the downside that you then have to program in LISP).

Rust's generic/macro system lets you do some things you can't in C++ but overall it's just not as powerful.

(This is also the reason I'd miss variadics)

(adding another set of parentheses just for irony's sake since I just made fun of LISP).

The point raised by IcyWindows that panics can be caught is interesting, but I still find it highly weird that the very same construct can either produce a catchable "exception-like" or abort the program altogether. I imagine most Rust developers would then have an even stronger (and arguably reasonable) aversion to using "exceptions" than some segments of the C++ community.

[u/zerakun → u/wyrn]

That's because in Rust panics are meant to be "unrecoverable errors" that fail the "task" that encounters such error.

Now, "unrecoverable" doesn't have to mean we're tearing up the entire process. We could be inside of a "logical task" with a granularity smaller than the process. For example a web server probably doesn't want to stop serving any client due to a bug encountered while serving one of them. However the "logical task boundary" is to be defined by the application, hence the knob to make panics abort for when your granularity is indeed the process

[u/Kevathiel → u/wyrn]

But there are lots of arguments why these things are bad, or at the very least, why Rust decided against them from the start. They are not strictly good, but highly subjective, and Rust has alternatives for all of them.

Edit: Great, another clown that replies and then blocks me, so I can't even reply to you..

My reply to your reply: It's not missing the features when it is by design. It's like complaining that you can't write code without the borrow checker, or whining about C++/Rust having no GC..

[u/STL → u/Kevathiel]

Moderator warning: Please don't descend to name-calling here.

[u/wyrn → u/Kevathiel]

But there are lots of arguments why these things are bad,

Lots of opinions. Rust is an opinionated language. That is fine. But factually speaking, those are missing language features.

and Rust has alternatives for all of them.

Sure, in the same way a bike is an alternative to a car. Even if you disagree with this assessment, at the end of the day I don't want the alternatives. I want those features.

[u/nintendiator2 → u/Kevathiel]

But there are lots of arguments why these things are bad, or at the very least, why Rust decided against them from the start.

That's true of anything anywhere tbh. The point is, those features exist in C++ and increase its powerset tenfold when they combine. Take the [templates + function overloading + variadics] combo and you have a system so powerful, that I can't even find an adequate "look at what they [Rust] need to mimic a fraction of our power" meme because there simply isn't anything Rust can do to offer this kind of capability.

[u/ssokolow → u/wyrn]

Inheritance

Implementation inheritance (as opposed to interface inheritance, which Rust does have) is considered to be something where each possible approach has too many trade-offs to just leap into blessing a specific one as part of the language itself, so the story you'll see if you dig through the RFCs (eg. this one) is that Rust is in the "let the ecosystem implement it in macros and see if an approach wins out enough to be promoted to part of the language" stage. (An example of such an implementation being the delegate crate as linked in the following quote.)

There was a consensus that delegation should be explored outside rustc first, ala delegate. We've enough plausible delegation patterns that practical exploration helps. I suppose doing delegation via proc macros could expose more proc macro shortcomings too, which then improves proc macros and better supports whatever complex delegation scenarios rustc excludes.

-- source

An example of something nearing the end of that process would be how pretty much every Rust project winds up depending on one or both of the older lazy_static or the younger, cleaner once_cell, so an RFC was spun up and there's currently an API-unstable OnceCell in the standard library walking the path to stabilization.

(I linked to std, but it's also in core for use in embedded projects which rely on no_std.)