Comment by anonymous908213 | Hacker News Reader

Comment by anonymous908213 | Hacker News Reader

Parent Full thread

anonymous908213

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.

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

sry wrong link: https://news.ycombinator.com/item?id=50365335

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.

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

Reply on news.ycombinator.com