Hacker News Reader

Comment by drivebyhooting | Hacker News Reader

I used to be a C++ programmer but I haven’t done it in a few years.

I pretty much do all my low level vibe coding in Rust. Is C++ still relevant? What prevents Rust from completely supplanting it?

View on HN

Even if C++ is irrelevant for new code, there's so much software already written in it that we'll be maintaining it for decades to come. I'd argue that Cobol and Fortran have been mostly obsolete for new code for almost 30 years now, yet both are still widely used today, and they've even had major updates in the past decade [0] [1]. And there's even more software written in C++ than there is in Cobol or Fortran, so I don't think that C++ is going away any time soon.

[0]: https://en.wikipedia.org/wiki/COBOL#COBOL_2023

[1]: https://en.wikipedia.org/wiki/Fortran#Fortran_2023

with ai their future seems very uncertain. ports are now very easy, so languages have to stand in their own merits

That is a myoptic view. Old codebases often have their value measured in the tiny problems thay were ironed out over the decades and the knowledge that they cover their subject domain correctly. A complete rewrite loses all of this in an instant amd has to start from scratch.

Essentially all high-end systems code for high-performance and high-reliability systems is still written in modern C++. That language has many attractive properties, including safety features that Rust does not currently support.

Additionally, for pure performance requirements, C++ is still materially faster than Rust in practice. That may change some day. C++ has many issues but it is also objectively excellent at many things.

> That language has many attractive properties, including safety features that Rust does not currently support.

Could you expand on what specific safety features C++ has that Rust doesn't?

C++ is the third most popular programming language according to TIOBE behind C and python. It's got an 8.87% ranking. So yes it looks like C++ is still relevant. In fact C++ usage has risen slightly.

Rust is in tenth place with 1.44% ranking, it's rising fast but still has a long way to go before it catches C++.

I'm not going to speculate about why Rust hasn't yet supplanted C++ but I will say I don't find it surprising.

TIOBE is nonsense.

But, of course, there is still a lot of new C++ code written, more than Rust. I believe C++ will become legacy, but it's not there yet and even once that happens it'll take at least decades to stop writing C++.

Please for God's sake stop citing TIOBE.

A much more accurate snapshot would be Github - they recently published the top langauges for the year (so far, up til Sept 2026) by distinct monthly contributors and C++ comes in at 9 out of the top 10, and Rust doesn't even place in the top 10 yet, so yes it is highly relevant and prevalent, but not because TIOBE said so.

But, TypeScript, Python and Rust are the fastest growing languages, in that order, so also you cannot discount Rust.

https://github.blog/news-insights/octoverse/octoverse-commit...

You didn't mention why people shouldn't cite TIOBE so I checked. It's because they measure search engine queries to assess popularity. GitHub measures actual code usage in real repos.

I agree the GitHub methodology seems better. I don't think TIOBE methods mean that it's ranking is completely irrelevant but it'll be noisy and you could easily game it.

Github is also skewed because it only captures a subset of open source projects, and open source is realistically a teeny tiny fraction of the world's written code.

Yes, GitHub is heavily skewed towards "hip" projects.

> Is C++ still relevant? What prevents Rust from completely supplanting it?

A highly mature ecosystem with well-established libraries. Especially in certain fields (DSP, robotics, CAD kernels, microcontrollers, etc.), there are no equivalent libraries and frameworks in Rust with such a proven track record.

Now, LLMs can rewrite those libraries in Rust quite easily. Such options weren't available a few years back. But it's still hard to prove that a rewrite hasn't introduced new bugs. It's easy to demonstrate that a piece of code has bugs, but much harder to prove that it doesn't introduce any new ones.

Additionally, even if an LLM-created Rust port of a C++ library was bug-free, an LLM cannot recreate the community that has evolved around the library.

Take PROJ for example, which is the de-facto coordinate systems library in the geospatial world, mostly written in C++. The processes and trust built up with external organisations like national mapping agencies is irreplaceable.

That hasn't stopped people trying to vibe-clone PROJ in Rust though.

> ...an LLM cannot recreate the community that has evolved around the library.

This is, in fact, an excellent point. You can ask an LLM to expertly clone or re-create any project in a different programming language. But that doesn't make you (or anyone else) an expert in that field, let alone competent in such a new codebase. Slowly developed, painfully debugged projects have a community of human brains who care about the topic. An LLM clone has nothing like that.

99.9% of all system code in the world is still written in C/++. It runs your Java, C#, Javascript, Python, PHP, basically every production language that isn't Go or Rust. It runs the two most popular game engines in the world. It runs your phone, server, and laptop, no matter which of any you use. It runs your car. It runs almost every embedded and industrial application on the planet.

Is it still relevant, JFC. The way people on this forum manage to sequester themselves from reality. Let me reverse the question: is Rust relevant? Mozilla developed Rust, abandoned their Rust browser, and only 10% of Firefox is written in Rust. Maybe 1% of modules in Chrome and Linux are written in Rust, if that. And what of Rust applications written from scratch? Can you name ten applications that have, say, exposure to more than 100,000 users? Impossible mode: they can't be developer tools only used by other developers (uv, ripgrep, etc.), they must actually be applications used by enterprises or consumers.

As a big c++ fan, new projects are generally choosing Rust, which I would agree with, even though I do indeed love C++

I read that as "is c++ still relevant for new features, given Rust and its popularity", not "who is still using C++".

Personally, I think it is still relevant. Many people thought Kotlin could overtake Java, Java reinvented itself with new initiatives/features and was saved from becoming irrelevant.

Rust also has the LLM advantage which is where I think the "if it compiles it works" nature of Rust is easier for manual changes and maintenance when needed.

Java vs. Kotlin is a different matter. It's still an open question if C++ even could match Rust's features, not to say if it (the committee) wants to, and the answer seems to be "no".

The feature parity question goes both ways: rust won't ever be able to express some things that are possible in C++.

Like?

Algorithms that safely mutate the same data structure on multiple threads and do so safely because of some complex algorithmic properties that guarantee that the changes do not overlap?

Why can Rust not do that?

How do you create shared mutable ownership of overlapping ranges of a single flat array in rust?

similarly except the algorithm to Mutex<[T]> and Arc?

How does this work e.g. for an array of integers that several workers threads write to at random, non-overlapping positions?

1. by implementing your complex algorithm? 2. if they don't overlap, they can't be random, can they?

Rust can literally do anything programmatically. Idk why you think it cannot do something.

They can be unordered, e.g. when reshuffling data into a new buffer based on a permutation that was computed separately. How do you avoid locking the output buffer in rust?

https://news.ycombinator.com/user?id=afdbcreid

Rust can do that just fine. https://doc.rust-lang.org/stable/std/cell/struct.UnsafeCell..... "some complex algorithmic properties that guarantee that the changes do not overlap" are exactly the place to use unsafe and encapsulate it.

If you mean things that formally create a data race, then C++ cannot do that either.

> basically every production language that isn't Go or Rust.

Even in their case. Rust depends on LLVM which is wriiten in C++. Go needs libc on some platforms.

Your Rust very likely runs in a C / C++ environment.

rust depends on C++ (LLVM)

Reply on news.ycombinator.com