zlacker

This is why I think that C++ will be around in the next 50 years but Rust? I can't tell.

>>twen_t+(OP)
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."

>>twen_t+(OP)
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.

>>silon4+hf
There's nothing to be caught up with. C++ is a different language with different tradeoffs than Rust. I hope it stays that way

>>twen_t+(OP)
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?

>>chilli+d1
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.

>>silon4+hf
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.

>>treali+nI
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.

>>surajr+7L
> 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.

>>uecker+ls1
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