Hacker News Reader

Comment by layer8 | Hacker News Reader

C++ precedes Rust by ~30 years. Just wait how large the Rust surface area might have become in 2053. There’s lessons to be learned from history, so hopefully less, but about every successful language so far has only kept growing and becoming more complex.

View on HN

Indeed it's already grown `async` and `?` since 1.0. But I love those features, they're a good thing.

In Rust, the compiler still checks everything. I can't mis-use async or the question mark operator and accidentally make my code unsafe.

In C++, I'm expected to know everything about every feature I use, so I have to be paranoid. Sure I remember that unique_ptr isn't atomic, do my juniors remember that? Sure, returning a reference to a local variable is a warning, but it's not an error, right? Many less-healthy teams probably ignore those warnings. And I myself don't even remember the rules for SFINAE or `move` in full. Not to mention that OpenCV's mix of shallow and deep copying for matrices casually breaks `const`.

In Rust, more surface area is just more Lego bricks. If two Legos snap together, you're safe. If they don't, don't force them. C++ expects you to force everything and take responsibility for not being a human encyclopedia of the language.

Is it not possible to use a linter with C++ that can tell you when you have done X or Y incorrectly?

surely, there is tooling that can help right?

It is possible to use C++ with a linter to help detect errors, but linters do not catch all errors nor do linters always understand what you are trying to do.

Most approaches to using C or C++ safely involve throwing out large portions of the language and disallowing features that are easy to misuse or problematic to analyze for safety.

Not all of the issues you can create in C++ are visible at compile time. That’s kind of the point.

A lot of the time you’re going to need to lean on Valgrind. And that’s AFTER you shipped a fatal crash and you’re parsing a tombstone.

Often no, for multiple reasons.

Separate compilation means that even if you write an interprocedural static analysis system (quite a bit more complex than what most people would call a linter), you still run into oodles of hard boundaries where you can't look into other functions. Fixing this requires explicit annotations all over the place to even have a chance.

C++ is also a remarkably complex language in terms of aliasing relationships. There are a bazillion ways you can make two names alias each other. This gives you a few options when writing an analysis. You can be sound and do weak updates everywhere, which means your alarms will basically never be confident. You can be unsound and assume no aliasing, which means that you've got a lot of false alarms. You also can't really make a rule "don't ever create aliasing relationships" because they are often idiomatic C++.

And finally, the key properties that people really deeply care about like heap lifetimes fundamentally involve complex reasoning about both temporal properties, dataflow, and heap shape. All of these are hairy static analysis problems. In combination, a nightmare.

Maybe. But my employer doesn't have those tools. Assuming we're a median team, then half of all c++ teams don't do any static analysis or even know how to use valgrind properly. (The only tools that looked useful to me were the ones that incurred a thousand x slowdown, and our code is too crappy to run correctly at different speeds)

Almost every feature is a good thing. But the total quantity can become a bad thing, because the interactions between the features become more and more complicated. It's almost like features have values proportional to the number of features, but they have costs proportional to the square of the number of features. You eventually reach the point where new features add more cost than they add value.

But it's not that simple, because each new feature adds value to a subset, but adds costs to everyone. If the subset is vocal, they often get what they want, even if it's a net loss for all users taken as a whole.

So the trick is, first, to stop adding features once the costs outweigh the benefits, and second, given that you have only a finite number of features that you can add before you reach that point, to add the total set of features that are going to make the most valuable language.

Yes but actually no. In rust the compiler handles interactions between features for you. C and c++ don't. Per my previous Lego analogy.

"Sure, returning a reference to a local variable is a warning, but it's not an error, right? Many less-healthy teams probably ignore those warnings."

Seriously?

Rust has the advantage of seeing the mistakes of the past and not making them. Many intersting ideas have been tried, only after significant use do we discover which are good and which are bad.

Compromise is sometimes needed. C++ had some ideas they knew at the time were bad, but backward compatibility forced it and backward compatibility is itself a great idea worth the costs.

Rust will have plenty of time to invent whole new categories of mistake, if it ever catches on. It started out with a raft of old familiar mistakes, and shed them over the years leading up to the 1.0 release, such as non-contiguous stacks and green threads. Maybe the way async is specified will turn out to have been one of the mistakes. It has, anyway, mechanisms to shed old mistakes that are not relied on much.

As it becomes popular eventually everything no matter how bad will be relied upon by many.

One of those history lessons is that change happens. This is why Rust has editions: allows for new features without breaking old code. There is still code complexity, but that complexity has been shifted/amortized into the compiler suite instead of everyone's project code.

Crucially, editions allow for deprecation, which is a trick C++ always had trouble with no matter how outdated the language construct.

I think the big problem with C++ was the “C” in it, that is maintaining compatibility with C (or sort of compatibility). Rust didn’t make this choice and it’s a completely new and different language.

Bad choices in C++ will ever change since you will break compatibility with a ton of stuff. Rust has the concept of “edition” that allows to migrate to new language versions gradually.

Surely the C++ surface area will also have increased significantly in the same span of time which means that Rust will still be ahead?

Probably, but how much is an open question.

By then, there may be a newer "new" language that is simpler than Rust.

>> Just wait how large the Rust surface area might have become in 2053.

This is a valid concern. One can hope that Rust evolves very slowly and as-needed. IMHO part of the problem with C++ is the fact that a committee exists to advance the language and produce regular updates. Combine that with most of the language already being defined (with a lot of overlap with C BTW) and you get a lot of bolted-on stuff and core features as part of the standard library that might have otherwise been part of the language with nice syntax. Rust had the advantage that a lot of things had been learned prior to its creation so things are cleaner. Lets hope keeping it that way is a priority and not just adding new things on top of new things - I think they're doing it right, but I don't really follow it.

C is great in this regard. The language is IMHO mostly "done" and rarely changes. I'm happy to use C99 and not much demands newer.

Looking at Wikipedia I'm afraid C is starting to get too many updates, but the 2017 version is said to add no new features! :-) https://en.wikipedia.org/wiki/C_(programming_language)

Well though-out languages gain complexity in a much slower rate than the carelessly put together ones. By orders of magnitude.

I doubt Rust will become as complex as C++ before it's abandoned in a few decades.

Why do you think it will be abandoned? Programming languages past a certain point don't die easily, especially when used for low-level system programming (otherwise C and C++ would be long dead).

All languages stop evolving at some point. C isn't there yet, but there are many dead languages that people only use because a lot of things are already written on it, and nobody wants to change anything.

So why does that mean Rust will be abandoned in a few decades?

Do you think there will be a trend "back" to using C or C++ for systems programming? I would bet against it. I do believe, by the way, that C has stopped evolving (which is good) and that C++ should stop evolving as well.

Or do you think the replacement of old languages by new ones will accelerate? So in 30 years most systems programming will be done in a language that doesn't exist yet? Maybe not done at all in a "programming language" as we have today?

Or do you think Rust is clearly losing out to some other new languages for systems programming, such as Zig, and will never be popular enough in the first place to enter the "slowly dying legacy" regime?

You don't need a "trend back to using C++". C++ usage is still growing by leaps and bounds. The number of people picking up C++ for professional use, in any short interval -- used to be two weeks, now a bit longer -- is more than the total number who are coding Rust in production. That will be true for a long time.

Rust could still catch on.

How are you calculating the usage numbers here?

Reply on news.ycombinator.com