In you opinion, doyou think C/C++ died later

Rust is the new programming language that will—over time—either complement or replace C/C++ in terms of memory efficiency, speed, and productivity. Furthermore, Linux, with its COSMIC desktop environment written in Rust, is redefining the standards for graphical environments—it’s very smooth with few bugs, which reduces the constant bugs we used to encounter on other environments that would sometimes break after an update (Arch Linux, in particular). What do you think of this programming language

legacy software won't change nor vanish. but please keep making nice stuff with suitable tools. just try to avoid the weird hubris rust seems to engender.

C++ is doomed to fail. The only reason people use it is because large projects are already written in it and it used to be the only widespread language next to C. C and C++ compilers merged into one over time. Everyone compiles their C with a C++ capable compiler now even though C follows different rules. Rust is like kicking dead whales down the beach too but it will be available on every platform and required by system stuff, so C++ will no longer hold the title of only compiled language next to C "already installed". Not even Bjarne knows C++ well. In my opinion many of the other competitors are better. I personally think D is the best.

>>44399 D is more magical and adhoc, it basically takes C++ ideas and implements them in even more trippy and possibly obscure ways, Rust is more structured and logical and elegant.

RIIR is an autistic practice and won't bring business value to companies, so there isn't going to be a whole lot of serious replacement going on outside of soykafty startups. Most of the time it seems like rust translations are being done by AI, and nobody trusts them, such as what happened to Bun. Rust doesn't even have a stable ABI, and likely won't for a long time. As much as I'd like to see C++ die, it won't happen in my lifetime

>>44401 > In December 2023, the first drivers written in Rust were accepted, and released in kernel version 6.8.[3][4] In December 2025, it was announced that Rust in the Linux kernel is no longer experimental with Rust development becoming an official part of kernel development. [5] https://en.wikipedia.org/wiki/Rust_for_Linux

>>44402 So what? I'm all for making new stuff in Rust, doesn't mean C is in any way dying, in the kernel or otherwise. I doubt we will see many serious efforts to rewrite battle-tested kernel components into rust either.

>>44402 good luck getting >10% of the core developers to write rust...

>>44382 I do system programming/parallel computing in all three languages, and so far each and every language has it's own strengths and weakness. C is basic and simple, with about 30 keyword you can basically build everything you want. It still has it's place in systems programming (Unix) because no language is ever going the replace the primary abi that every other language relies on. C++ is the king for data processing, it has the best library support, native cuda, opencl, (vulkan if you're into that), openmp and openacc work on it too. While you can technically use rust for all of those, it's still not mature enough and barely has a working cuda library. Also pretty much any C library will work in C++, and you can even wrap C library handles into unique_ptr to make sure you don't mess things up. Rust is starting to catch up to C++ in the data processing world. It has libraries like rayon which are direct alternatives to openmp. Systems programming in rust basically requires you to know what system call every method will issue. Like rust has a very specific method to do file i/o that will result in copy_file_range or sendfile, instead of a read+write loop. It's main strength is that you either write very optimized code naturally in it, or you put everything in a refcounted mutex and clone() whenever. It has a java-like bureaucrary built into it, especially with the turbo pascal casting style. I've used drogon (c++ web framework) and axum/actix in rust, and yeah rust idioms work much better. especially when every single function/method you write may be called in a separate thread. C++ is the language where technically everything is possible, but every time I start a C++ project I have to define a bunch of stuff that are missing form the standard. For instance <filesystem> is 100% garbage. The first implementation had mandatory exceptions when any basic fs operation fails, if stat fails you have to handle an exception to know about it. They quickly fixed it by adding a C-like api with an error code you (should) check instead of exceptions. But <filesystem> is a HUGE cve generators (TOCTOU) because they didn't define a file handle. So every operation happens on path strings, which as you know doesn't guarantee that the file hasn't been modified. Modern OSes will give you file handle and make the guarantee that the file remain accessible as long as the handle exists (even if the file is deleted). Also, one of the main things I like from rust (which are a consequence of it's single implementation), are proc macros. Proc macros are much more powerful once you consider there's only one implementation and that UB that works is not really UB. For instance you can use proc macros to read files on disk. Then you can have proc macros emit tokens from these files by doing a simple tokenization pass on it. That allows you to write DSLs that directly transpile to rust code, which then gets compiled and optimized by LLVM. You can do that in C++ too, using variadic templates, you can even embed a program as a string that gets compiled to C++ within C++. But it's just way too ugly and impractical (and astonishingly slow). C++ also suffers from outdated default. Nowadays you always want to annotate a method with [[nodiscard]] constexpr + noexcept when applicable, I think these should be opt-out instead, but we can't have backward compatibility otherwise (C++'s main strength IMHO). If I were to make a new desktop application in C++, there's no way I'm not including libicu, rust on the other hands gives you a lot of nice tools readily available in the standard library. Now talking about politics for C++; a few years ago, the standard wanted to add a computing device api, which would allow you to easily offload code to run on mutliple cores, distributing code to GPUs, etc.. Well guess who veto'ed that? Our favourite green company. It's a similar situation as when IBM/Oracle/Sun vetoed std::thread because it's performances would obliterate their (green) thread implementation in the JVM. That's actually the reason why C++11 (initially C++03) took so long to ship. Currently, if the features planned for c++26/29 make it into the language (reflection in '26, lifetimes in '29) the language will become so complex that the most sought after position will be trainers/teachers and not engineer. Well reflection made it but we'll see how it's implemented and how it interacts with the current ecosystem. Personally, I really like C because of it's simplicity. Complexity doesn't come from the language, rather it comes from whatever you're building with it. No magic containers implementation that breaks when you change vendor. No monomorphization, the code you see is the code that gets compiled, no magic. That said, it's still a good language because it forces you to think before doing anything. C teaches rigor and forces you to RTFM. But it can be a little too overwhelming, when you primarily think about implementation instead of logic and code flow. Personally, the main things I dislike from rust are the fact that there's only one competing implementation and the npm-style package management. Sometime you build a 5-deps projects and it recursively pulls 600+ dependencies. While it may not be a problem for now, you've go to think about what happens when any of these 600 dependencies becomes outdated, unmaintained, or worse. At this point cargo becomes more of a liability than a feature. Also for various (good) reasons, rust is allergic to dynamic linking. While I think it's a good thing for open source, it heavily restrain the ability for (proprietary) vendors to ship native rust libraries (otherwise they have to make their libraries accessible through the C abi).