Hacker News new | ask | show | jobs
by twen_ty 889 days ago
This is why I think that C++ will be around in the next 50 years but Rust? I can't tell.
3 comments

Some might think C++ will take years (few years I was hoping 2025, but seems unlikely now) to catch up to Rust in some important ways.
C++ is losing momentum as larger organizations lose interest in investing in it. Features standardized in c++20 are still not available in the most popular compilers, let alone features in c++23. The future is looking bleak.

Rust is a great alternative for greenfield projects but we really need a new kotlin-esque innovation to keep c++ alive imo.

> Features standardized in c++20 are still not available in the most popular compilers

"A few years" was also the feature support cadence of '17 through '11 features.

And, before that, the 3-year release cycle wasn't a thing yet.

There's nothing to be caught up with. C++ is a different language with different tradeoffs than Rust. I hope it stays that way
I'm sure legacy C and C++ will be around for a long time, but their process for authoring new standards also seems somewhat unsustainable.

It seems like people making contributions to the C and C++ standards are also at risk of getting burnt out: https://thephd.dev/finally-embed-in-c23

> It was all worth it.

> …

> Or. That’s what I keep telling myself. Because it doesn’t feel like it was worth it. It feels like I wasted a lot of my life achieving something so ridiculously basic that it’s almost laughable. How utterly worthless I must consider myself, that hearing someone complain about putting data in C++ 5 years ago put me on the track to decide to try to put something in a programming language standard. That I had to fight this hard for table scraps off the Great C Standard’s table.

> What a life, huh?

C is/was fueled by positive energy: "Let's be (relatively) portable and improve on Assembly."

Rust seems to have vengeful victory at its heart: "Let's sock it to those reckless, ignorant C programmers."

It's more like "let's improve on C by catching errors C compilers don't check." Rust took a lot of inspiration from Cyclone, which was meant to be a safe version of C.

Writing C makes certain classes of sloppy assembly bugs unwritable, like accidentally using the wrong calling convention, forgetting to preserve a register, or forgetting to pop something off the stack. Similarly, Rust makes classes of sloppy C bugs unwritable, like using a dangling pointer.

Why do you view that as an attack on C programmers? It's no more an attack on them than C was an attack on assembly programmers.

The attack is the idea that everybody needs to have the same priorities that Rust has and so everybody else is wrong. With regard to memory safety, this even something I could partially agree with, but then there is another problem: In contrast to Cyclone, which was a safe version of C, Rust changes a lot more than simply adding memory safety features. It is not at all like C but has completely different syntax, different conventions, and complexity similar to C++. So in many ways, I find it inferior to C (although I agree that memory safety is good), but Rust people think it is superior in every way and behave like this.
It's true, not everyone has the same priorities, and Rust may not provide the right set of tradeoffs when one is deciding which language to use. I don't believe that C is strictly inferior to Rust. There are cases where it's not worth trying to use Rust instead of C.

Unsafe Rust is more complex to use than C in some ways. For example, an iterator for a slice, which contains two raw pointers, relies on the lifetime of the array it refers to lasting longer than the slice, and to encode this you need to use PhantomData [1]. Things like this make it look more arcane than plain C, simply because in C, this is implicit, and on the programmer to enforce.

[1]: https://doc.rust-lang.org/nomicon/phantom-data.html