11 ms·

Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.

• boppo1 1y ago
  Sarcasm?
  • grg0 1y ago
    These comments only reflect the person's narrow view of the "world", along with a generous dosage of pride to state things about which one does not know. If every OS and driver and much of the backbone of society is "legacy maintenance stuff", then the statement is certainly correct.
• bukotron 1y ago
  Rust does not solve any problem existing in expecienced C++ developer career. You dont write modern C++ code in such a way memory leak or dangling pointer is possible at all) This is exactly WHY we dont see a rush movement of C++ developers to Rust throwing away everything for Rust. Rust is trying to solve problems that already not exist 99.9999% of time in modern C++ code style and standards. Also, some day C++ compilers or tooling will get its own Borrow Checker to completely forget about Rust - this will be done just for fun just to stop arguing with rust-fans :)
  • Philpax 1y ago
    Thinking that experience with C++'s many flaws will save you from running into them is delusional - just look at the number of CVEs in projects maintained by world-class C++ programmers. No amount of fallible human vigilance will stop you from forgetting the existence of a C++ quirk in the code you're rushing out before heading out for the night. Human oversight does not scale.
    • InCom-0 1y ago
      This is true ... except that Rust doesn't actually do any better in that regard. Rust solves 1 category of problems in a way that is not without its costs and other consequences. That is it. There are projects where this is very important, there are other projects where its virtually useless and the consequences just get in the way. It is not magic. It doesn't make anything actually 'safe'.
      • feelamee 1y ago
        sure, but don't forget that rust gives us also a nice tooling, functional syntax sugar like pattern matching, enums, monads; and other more or less useful things like explicit lifetimes
        • InCom-0 1y ago
          Of course. This is kind of to be expected as it has the benefit of hindsight of 25+ years. It is infinitely easier to design better things with all the accumulated experience and know-how of what works and what doesn't under your belt. It would have been truly horrifying if that had not been the case. That being said, Rust is really about lifetimes. That's the big ticket selling point. My point above was that 1) it isn't a silver bullet and 2) it can be a real hindrance is many applications.
        • flohofwoe 1y ago
          Tbh, only a mother can love Rust's syntax. It has even more "punctuation" than C++.
        • sobakistodor 1y ago
          [dead]
      • dlahoda 1y ago
        what is this 1 category?
    • flohofwoe 1y ago
      When looking at the number of CVEs you'll also have to take the amount of code written in that language into account, a language which has no users also has no CVEs ;) I bet there's easily tens of thousands of times more C++ code than Rust code out there.
  • okanat 1y ago
    This is a very bad take. Rust does solve very real problems in C family languages. The number of people I met in Rust conferences that rewriting at least parts of rather big C++ codebases weren't small either. However, there is still big amount of code that is purely C++. Many of the older code bases still use C++03-style code too. Or they were written in the OOP design pattern golden era that requires huge reactors to adapt functional / modern code. Anything with Qt will not benefit from smart pointers. Even with Qt 6. Rust cannot solve these problems since the challenges are not purely technical but social too.
    • r_lee 1y ago
      I would say though that Rust has already had a profound social effect which has probably enabled those rewrites etc. It wasn't too long ago that it was brushed aside as noise yet now its gaining real momentum
• c0balt 1y ago
  I'm pretty sure a lot of fields would disagree with you. Last I checked game programming, OS development, embedded development and more were deeply invested in either C or more often C++, especially when RT tasks were involved or vendor-provided compilers are required. Rust just doesn't have close to the same type of adoption/support yet, especially when considering various embedded platforms.
  • holowoodman 1y ago
    There is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.
    • jonathrg 1y ago
      C++ is widely used in embedded. Most compilers support it. Usually you turn some things off (e.g. -fno-rtti, -fno-exceptions) and try to stick to some sane subset of the ++.
      • com2kid 1y ago
        C++ in embedded is basically C with classes. It is a nice simple language and often doesn't even include templates (or if it does they are very simple data structures that are not even heap allocated). C++ as C with classes is a pretty good language!
        • deleted 1y ago
          [deleted]
    • grg0 1y ago
      Game engines (the thing that C# runs on top of) are written in C++. As is the C#/.NET runtime. As is anything that requires careful management of memory for performance. Application code is perfectly reasonably written in managed languages, but not so for the things that run underneath.
• okanat 1y ago
  Newer stuff yes and it is great. However from basic rendering to browsers and the most complex applications (CAD, office software, finance, complex solvers like airline planning) are still in C++. Nobody will accept rewriting 35+ years of history. C++ code bases are really a lot longer-lived than any other software builds upon them. Hence we cannot drop it. Starting with C++17, I think committee has been doing the language a disservice and piled even more and more unintended complexity by rushing "improvements" like modules. I don't write C++ anymore due to my team switching to Rust and C only (for really old stuff and ABI). I am really scared of having to return though. Not because I am spoiled by Rust (I am though), but because catching up with all the silly things they added on top and how they interact with earlier stuff like iterators. C++ is a perfect language for unnecessary pitfalls. Newer standards just exploded this complexity.
  • jonathrg 1y ago
    I understand and empathize with your fear. C++23 added a type with 22 constructors (http://en.cppreference.com/w/cpp/utility/expected/expected.html http://en.cppreference.com/w/cpp/utility/expected/expected.h...), that ought to be enough to strike fear into anyone.
    • okanat 1y ago
      It already has a defect report too: https://cplusplus.github.io/LWG/issue3886 https://cplusplus.github.io/LWG/issue3886 .
    • samiv 1y ago
      Don't worry, C++25 will deprecate half of them and C++27 will remove them while adding 20 new ones just to be deprecated in C++30.
      • okanat 1y ago
        C++ standard and deprecation is a contradiction. They almost never deprecate things. Things always go more complex.
• whatevaa 1y ago
  Borrow checker is actually not very good solution for some domains. I remember reading that it would not be good for writing javascript VM like v8. Something about managing memory which lifetime actually depends on others, not rust code.
• fooker 1y ago
  C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.
  • Philpax 1y ago
    A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add, but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant` is, as far as I know, still limited, even in newer C++ code, because the ergonomics just aren't there.
    • fooker 1y ago
      optional is heavily used in new codebases. variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. C++ does have quite a bit of rot, you're right. But that's the price of building technology people actually use. Carbon doesn't seem to have any fundamentally new ideas, we'll see how well it fares in the wild.
      • ghosty141 1y ago
        > variant isn't, yet. We'll eventually get some kind of structural pattern matching that will make variant or it's successor more idiomatic. Thats the fantastic thing about c++, you can already write an easy to use match, but they just chose not to include that in the stdlib but rather want you write that yourself. Example: match(foo, [](Foo&) { }, [&](Bar& bar) { }, [&](const auto& mode) { // catch all }); Also optional and expected are ergonomic nightmares since there is no "try!" macro like rust has. In general it lacks the infrastructure that is needed to make these types nice to use. It also clashes with other concepts like RAII where you kinda have to use exceptions when it comes to ctors that may fail.
• diath 1y ago
  There are a number of areas in programming where I'd always choose C++ over Rust - gameplay programming, retained-mode GUI programming and interpreted programming languages to name a few have very complex circular memory models that are somewhat solvable with weak_ptrs or refs stored in member variables passed through constructors but would be absolutely obnoxious to deal with and get right with the borrow checker.
  • ozars 1y ago
    Rust has Arc and Weak that can be used for solving it in a similar way C++ does. The primary difference is forcing usage of Mutex to avoid a large class of data race issues IMHO, and that's what makes it harder to get right. Async in Rust is also more mature than C++ coroutines. So there's also that. https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=02e9565e45119d0bdb9859544ad0d58c https://play.rust-lang.org/?version=nightly&mode=debug&editi...
    • MindSpunk 1y ago
      Arc/Weak can only get you so far. The problem I have with Rust in the mentioned domains (gameplay programming, retained GUI, interpreters) is what makes it so good, sharing xor mutability. If you're writing lots of multi-threaded code it's fantastic. If your problem domain is like the ones mentioned it hurts you. These are all highly non-parallel problems. They don't gain much from being parallel, and because Rust imposes 'restrict' semantics on even single threaded code you end up making it much harder to write code in these domains. This has been my experience with Rust. Shared mutability is safe on a single thread without 'restrict' on all your pointers, and Rust has limited options to opt into shared mutability (with lots of ergonomic caveats). Don't get me wrong though, I still think Rust is a great tool. It just has tradeoffs.
      • zozbot234 1y ago
        > Rust has limited options to opt into shared mutability The idiomatic Rust equivalent of a C non-restrict pointer is arguably &Cell<T>. The biggest problem with it is library code that takes &mut T when the likes of &Cell<T> might suffice (because potential aliasing does not affect the semantics of what that Rust code is doing), but this is an acknowledged problem and the Rust project will take pull req's that fix it where it occurs.
• InCom-0 1y ago
  Have a look at any serious job postings. C++ jobs outnumber Rust jobs somewhere around 50:1. Internet hype meets actual industry reality :-).
  • tandr 1y ago
    Or could it be (or to be a bit of devil's advocate) that Rust projects require only 2% (1/50) of manpower, comparing the same project using C++?
    • lyu07282 1y ago
      I couldn't even tell if you are joking. Rust is weird, its like a programming language people developed a parasocial relationship with. If a Twitch streamer was a programming language it would be Rust. Perhaps its just people being immature I don't know.
      • feelamee 1y ago
        > I couldn't even tell if you are joking I'm thinking the same about your comment :D
        • lyu07282 1y ago
          It's a programming language with a fandom, isn't that odd? ^^
      • tandr 1y ago
        I was, but I guess adding /s at the end in these cases is a requirement nowadays...
    • Dylan16807 1y ago
      That's not devil's advocate, that's just being silly.
    • SkiFire13 1y ago
      Even if the basic idea might make sense there's no way the number if anywhere close to 1/50. Even 1/2 sounds unrealistic.
• spacechild1 1y ago
  How did you get that impression? There are many areas where C++ is still the first choice. Also, "legacy maintenance stuff" is quite an understatement, given how much of our world is powered by C++: browser engines, language runtimes, game engines, video editors, DAWs, automation software, medical equipment, flight control software, etc. If you think that "the world seems to have moved on to Rust", I would recommend to look at the job listings. For example, devjobs.de: Rust: 61, C++: 1546. That's 1:25. Maybe in other countries there are more Rust jobs?
• flohofwoe 1y ago
  Rust isn't exactly famous for its fast build times. It's probably the only language that actually builds slower than C++, which is an impressive achievement on its own ;) And give Rust one or two more decades and it will be the same messy kitchen sink language as C++. If anything, Rust is speedrunning C++ history (with the notable exception of fixing static memory safety of course).