3 ms·

After learning Rust, C++ just seems unnecessarily complicated. I'm not even going to try to understand this. Using C++ these days feels like continuing to use

After learning Rust, C++ just seems unnecessarily complicated. I'm not even going to try to understand this. Using C++ these days feels like continuing to use the earth-centric solar system model to explain the motion of planets vs a much simple sun-centric model: Unnecessarily over-complicated.

deleted 11mo ago
[deleted]
drnick1 11mo ago
Rust just doesn't work for a lot of applications. Things like GUI toolkits, Web browsers, game engines are a pain to write without true OOP. Yes, it's "overly complicated" at this point after about 40 years of development, buts it's still top 3 of the TIOBE index after all these years for a reason.
- ogoffart 11mo ago
  Of course Rust can handle those use cases fine (GUIs, web browsers, and game engines). C++ is still high on the TIOBE index mainly because it is indeed old and used in a lot of legacy systems. For new projects, though, there's less reason to choose C++.
  - drnick1 11mo ago
    It's still high because it solves real world problems, so it's still the gold standard for anything ranging from systems programming to scientific computing.
  - Calavar 11mo ago
    Web browsers, yes. With GUIs and games, it's a less clear. Of course you can write GUIs and games in any Turing complete language but there's still a lot of work to be done in finding the right ergonomics in Rust [1, 2]. [1] https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-ha... [2] https://loglog.games/blog/leaving-rust-gamedev/ https://loglog.games/blog/leaving-rust-gamedev/
    - koakuma-chan 11mo ago
      You are saying "With GUIs and games" as if there is any GUI framework or game engine that doesn't suck.
  - deleted 11mo ago
    [deleted]
- steveklabnik 11mo ago
  The TIOBE index does not measure anything useful. I’d say this if Rust were at the #1 spot too.
- vlovich123 11mo ago
  I think you’ve misidentified the reason this stuff is harder in Rust and it has nothing to do with “true OOP” if by that you mean class based inheritance. The primary challenge is mapping how GUIs are traditionally mutated onto Rust semantics. Even then, efforts like Slint show it’s eminently feasible so I’m not sure your argument holds. It’s important to remember that c++ has a 30 year head start on Rust, especially at a crucial growth part of computing. Thats why it tops the TIOBE index. But I fully expect it to go the way of COBAL sooner rather than later where most new development does not use c++.
- Profan 11mo ago
  If anything OOP might actually be detrimental to many game engine applications (in a modern computing context in regards to the kind of data layouts and implementation patterns it encourages), and traits and "traditional" OOP (if you exclude implementation inheritance, which is largely cursed anyways) are real close together anyways, I think Rust is a great fit specifically for game engines at least, for gameplay programming I'm not as certain but for anything where you're mostly managing essentially data pipelines that need to go very fast and be reliable and not crashy, Rust is a great fit.
Pet_Ant 11mo ago
I feel like C++ is the counter-argument to backwards compatibility. Even Java is loosening it's obsession with it. Sometimes you just need to move forward. Python 3 should be studied for why it didn't work as opposed to a lesson not to do it again.
- 0xcafefood 11mo ago
  > Python 3 should be studied for why it didn't work as opposed to a lesson not to do it again. I'm curious about this in particular. It seems like the Python 2 to 3 transition is a case study in why backwards compatibility is important. Why would you say the lesson isn't necessarily that we should never break backwards compatibility? It seems like it almost could've jeopardized Python's long-term future. From my perspective it held on just long enough to catch a tail wind from the ML boom starting in the mid 2010s.
  - Pet_Ant 11mo ago
    Because you end up accumulating so much cruft and complexity that the language starts to fold under its own weight. Often you hear the advice that when using C++ your team should restrict yourself to a handful of features. ...and then it turns out that the next library you need requires one of the features you had blacklisted and now it's part of your codebase. However, if you don't grow and evolve your language you will be overtaken by languages that do. Your community becomes moribund, and more and more code gets written that pays for the earlier mistakes. So instead of splitting your community, it just starts to atrophy. Python 2 to 3 was a disaster, so it needs to be studied. I think the lesson was that they waited too long for breaking changes. Perhaps you should never go too many releases without breaking something so the sedentary expectation never forms and people are regularly upgrading. It's what web browsers do. Originally people were saying "it takes us 6 months to validate a web browser for our internal webapps, we can't do that!" ...but they managed and now you don't even know when you upgrade.
  - steveklabnik 11mo ago
    Part of the issue is that you can't just generalize it to "breaking changes." Ruby, very similar to Python, underwent a similar break between Ruby 1.8 and Ruby 1.9, but didn't befall the same fate. The specifics really matter in this kind of analysis.
swatcoder 11mo ago
Like C always will, C++ mostly still echoes the diversity of hardware architectures and runtime environments out there. That diversity is still broader than many people who don't work in weird specialties and fringes realizes, and it's useful to have a "modern" language that respects the odd quirks of those systems and how you sometimes need to leverage them to meet requirements. If you're just writing application software for consumers or professionals, or a network service, and it's destined to run on one of the big three families of operating systems using the one of the big few established hardware architectures at that scale, there are definitely alternatives that can make your business logic and sometimes even your key algorithms simpler or clearer, or your code more resistant to certain classes of error. If you look at Rust and see "this does everything I could imagine doing, and more simply than C++", there's nothing wrong with that, because you're probably right for yourself. But there are other projects out there that other people work on, or can expected themselves working on someday, that still befit C++ and it's nice for the language to keep maturing and modernizing for their sake, while maintaining its respect for all the underlying weirdness they have to navigate.
- creata 11mo ago
  > If you're just writing application software... there are definitely alternatives... Tangentially, is there a good alternative to Qt or SDL in Rust yet?
  - pjmlp 11mo ago
    Slint, done by ex-Qt employees.
  - bryanlarsen 11mo ago
    IMO, even better would just be good QT bindings that take advantage of the benefits of Rust. I haven't checked. The gnome bindings are pretty good, but the abstraction does leak through.
- duped 11mo ago
  > C++ mostly still echoes the diversify of hardware architectures and runtime environments out there It doesn't though, or at least none of those echoes are why C++ is complex. Here are some examples of unnecessary complexity. The rules of 3/5 exist solely due to copy/move/assign semantics. These rules do not need to exist if the semantics were simpler. Programmers need to be aware of expression value categories (lvalue, rvalue, etc). These concepts that most languages keep as internal details of their IRs are leaked to error messages, because of the complex semantics of expression evaluation. SFINAE is a subtle rule of template expansion that is exploited for compile time introspection due to the fact the latter is just missing, despite the clear desire for it. The C++ memory model for atomics is a particular source of confusion and incorrectness in concurrent programs because it decouples a fairly simple problem domain and rules into (arguably too small) a set of semantics that are easy to misuse, and also create surprisingly complex emergent behaviors when misused that become hard to debug. These are problems with the language's design and have nothing to do with the hardware and systems it targets. The thing that bugs me about this topic is that C++ developers have a kind of Stockholm syndrome for their terrible tools and devex. I see people routinely struggle with things that other languages simply don't have (including C and Rust!) because C++ seems committed to playing on hard mode. It's so bad that every C++ code base I've worked on professionally is essentially its own dialect and ecosystem with zero cross pollination (except one of abseil/boost/folly). There is so much complexity in there that creates no value. Good features and libraries die in the womb because of it.
psyclobe 11mo ago
I think Rust is unnecessarily safety focused. Opinions are cool.
- dehrmann 11mo ago
  But that's it's thing. C++ with improved syntax (think Kotlin for C++) isn't really enough to gain popularity. It's like how Dvorak is sorta better than qwerty, but it doesn't offer anything new, and it isn't so much better it justifies migrating.
  - pwdisswordfishy 11mo ago
    No need to imagine hypotheticals – this exists: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
TuxSH 11mo ago
> Unnecessarily over-complicated. Most of the complexity comes from the fact that C++ trivially supports consuming most C code, but with its own lifetime model on top, and that it also offers great flexibility. Of course things become simpler when you ditch C source compat and can just declare "this variable will not be aliased by anyone else" AFAIK C++'s constexpr and TMP is less limited than Rust's is.
- pjmlp 11mo ago
  Also, with all its warts, I find easier to stay within C++ itself, instead of two macro systems, that additionally depend on an external crate.
wrathofmonads 11mo ago
The real barrier is the C++ ecosystem. It represents the cost of losing decades of optimized, highly integrated, high-performance libraries. C++ maps almost perfectly to the hardware with minimal overhead, and it remains at the forefront of the AI revolution. It is the true engine behind Python scientific libs and even Julia (ex. EnzymeAD). Rust does not offer advantages that would meaningfully improve how we approach HPC. Once you layer the necessary unsafe operations, C++ code in practice becomes mostly functional and immutable, and lifetimes matter less beyond a certain threshold when building complex HPC simulations. Or even outsourced to a scripting layer with Python.
- amluto 11mo ago
  > C++ maps almost perfectly to the hardware with minimal overhead Barely. The C++ aliasing rules map quite poorly into hardware. C++ barely helps at all with writing correct multithreaded code, and almost all non-tiny machines have multiple CPUs. C++ cannot cleanly express the kinds of floating point semantics that are associative, and SIMD optimization care about this. C++ exceptions have huge overhead when actually thrown.
  - wrathofmonads 11mo ago
    In simulations or in game dev, the practice is to use an SoA data layout to avoid aliasing entirely. Job systems or actors are used for handling multithreading. In machine learning, most parallelism is achieved through GPU offloading or CPU intrinsics. I agree in principle with everything you’re saying, but that doesn’t mean the ecosystem isn’t creative when it comes to working around these hiccups.
  - jcalvinowens 11mo ago
    > The C++ aliasing rules map quite poorly into hardware. But how much does aliasing matter on modern hardware? I know you're aware of Linus' position on this, I personally find it very compelling :) As a silly little test a few months ago, I built whole Linux systems with -fno-strict-aliasing in CFLAGS, everything I've tried on it is within 1% of the original performance.
feelamee 11mo ago
I think rust has a lot of slippery points too. And this number will grow with years. So, yes - rust made a lot of good choices over C++, but this does not mean it has no its own problems. Therefore I can't say Rust is simple in this sense.. But, of course, this is a good evolution step.

deleted 11mo ago

[deleted]

drnick1 11mo ago

Rust just doesn't work for a lot of applications. Things like GUI toolkits, Web browsers, game engines are a pain to write without true OOP. Yes, it's "overly complicated" at this point after about 40 years of development, buts it's still top 3 of the TIOBE index after all these years for a reason.

ogoffart 11mo ago
Of course Rust can handle those use cases fine (GUIs, web browsers, and game engines). C++ is still high on the TIOBE index mainly because it is indeed old and used in a lot of legacy systems. For new projects, though, there's less reason to choose C++.
- drnick1 11mo ago
  It's still high because it solves real world problems, so it's still the gold standard for anything ranging from systems programming to scientific computing.
- Calavar 11mo ago
  Web browsers, yes. With GUIs and games, it's a less clear. Of course you can write GUIs and games in any Turing complete language but there's still a lot of work to be done in finding the right ergonomics in Rust [1, 2]. [1] https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-hard https://www.warp.dev/blog/why-is-building-a-ui-in-rust-so-ha... [2] https://loglog.games/blog/leaving-rust-gamedev/ https://loglog.games/blog/leaving-rust-gamedev/
  - koakuma-chan 11mo ago
    You are saying "With GUIs and games" as if there is any GUI framework or game engine that doesn't suck.
- deleted 11mo ago
  [deleted]
steveklabnik 11mo ago
The TIOBE index does not measure anything useful. I’d say this if Rust were at the #1 spot too.
vlovich123 11mo ago
I think you’ve misidentified the reason this stuff is harder in Rust and it has nothing to do with “true OOP” if by that you mean class based inheritance. The primary challenge is mapping how GUIs are traditionally mutated onto Rust semantics. Even then, efforts like Slint show it’s eminently feasible so I’m not sure your argument holds. It’s important to remember that c++ has a 30 year head start on Rust, especially at a crucial growth part of computing. Thats why it tops the TIOBE index. But I fully expect it to go the way of COBAL sooner rather than later where most new development does not use c++.
Profan 11mo ago
If anything OOP might actually be detrimental to many game engine applications (in a modern computing context in regards to the kind of data layouts and implementation patterns it encourages), and traits and "traditional" OOP (if you exclude implementation inheritance, which is largely cursed anyways) are real close together anyways, I think Rust is a great fit specifically for game engines at least, for gameplay programming I'm not as certain but for anything where you're mostly managing essentially data pipelines that need to go very fast and be reliable and not crashy, Rust is a great fit.

Pet_Ant 11mo ago

I feel like C++ is the counter-argument to backwards compatibility. Even Java is loosening it's obsession with it. Sometimes you just need to move forward. Python 3 should be studied for why it didn't work as opposed to a lesson not to do it again.

0xcafefood 11mo ago
> Python 3 should be studied for why it didn't work as opposed to a lesson not to do it again. I'm curious about this in particular. It seems like the Python 2 to 3 transition is a case study in why backwards compatibility is important. Why would you say the lesson isn't necessarily that we should never break backwards compatibility? It seems like it almost could've jeopardized Python's long-term future. From my perspective it held on just long enough to catch a tail wind from the ML boom starting in the mid 2010s.
- Pet_Ant 11mo ago
  Because you end up accumulating so much cruft and complexity that the language starts to fold under its own weight. Often you hear the advice that when using C++ your team should restrict yourself to a handful of features. ...and then it turns out that the next library you need requires one of the features you had blacklisted and now it's part of your codebase. However, if you don't grow and evolve your language you will be overtaken by languages that do. Your community becomes moribund, and more and more code gets written that pays for the earlier mistakes. So instead of splitting your community, it just starts to atrophy. Python 2 to 3 was a disaster, so it needs to be studied. I think the lesson was that they waited too long for breaking changes. Perhaps you should never go too many releases without breaking something so the sedentary expectation never forms and people are regularly upgrading. It's what web browsers do. Originally people were saying "it takes us 6 months to validate a web browser for our internal webapps, we can't do that!" ...but they managed and now you don't even know when you upgrade.
- steveklabnik 11mo ago
  Part of the issue is that you can't just generalize it to "breaking changes." Ruby, very similar to Python, underwent a similar break between Ruby 1.8 and Ruby 1.9, but didn't befall the same fate. The specifics really matter in this kind of analysis.

swatcoder 11mo ago

Like C always will, C++ mostly still echoes the diversity of hardware architectures and runtime environments out there. That diversity is still broader than many people who don't work in weird specialties and fringes realizes, and it's useful to have a "modern" language that respects the odd quirks of those systems and how you sometimes need to leverage them to meet requirements. If you're just writing application software for consumers or professionals, or a network service, and it's destined to run on one of the big three families of operating systems using the one of the big few established hardware architectures at that scale, there are definitely alternatives that can make your business logic and sometimes even your key algorithms simpler or clearer, or your code more resistant to certain classes of error. If you look at Rust and see "this does everything I could imagine doing, and more simply than C++", there's nothing wrong with that, because you're probably right for yourself. But there are other projects out there that other people work on, or can expected themselves working on someday, that still befit C++ and it's nice for the language to keep maturing and modernizing for their sake, while maintaining its respect for all the underlying weirdness they have to navigate.

creata 11mo ago
> If you're just writing application software... there are definitely alternatives... Tangentially, is there a good alternative to Qt or SDL in Rust yet?
- pjmlp 11mo ago
  Slint, done by ex-Qt employees.
- bryanlarsen 11mo ago
  IMO, even better would just be good QT bindings that take advantage of the benefits of Rust. I haven't checked. The gnome bindings are pretty good, but the abstraction does leak through.
duped 11mo ago
> C++ mostly still echoes the diversify of hardware architectures and runtime environments out there It doesn't though, or at least none of those echoes are why C++ is complex. Here are some examples of unnecessary complexity. The rules of 3/5 exist solely due to copy/move/assign semantics. These rules do not need to exist if the semantics were simpler. Programmers need to be aware of expression value categories (lvalue, rvalue, etc). These concepts that most languages keep as internal details of their IRs are leaked to error messages, because of the complex semantics of expression evaluation. SFINAE is a subtle rule of template expansion that is exploited for compile time introspection due to the fact the latter is just missing, despite the clear desire for it. The C++ memory model for atomics is a particular source of confusion and incorrectness in concurrent programs because it decouples a fairly simple problem domain and rules into (arguably too small) a set of semantics that are easy to misuse, and also create surprisingly complex emergent behaviors when misused that become hard to debug. These are problems with the language's design and have nothing to do with the hardware and systems it targets. The thing that bugs me about this topic is that C++ developers have a kind of Stockholm syndrome for their terrible tools and devex. I see people routinely struggle with things that other languages simply don't have (including C and Rust!) because C++ seems committed to playing on hard mode. It's so bad that every C++ code base I've worked on professionally is essentially its own dialect and ecosystem with zero cross pollination (except one of abseil/boost/folly). There is so much complexity in there that creates no value. Good features and libraries die in the womb because of it.

psyclobe 11mo ago

I think Rust is unnecessarily safety focused. Opinions are cool.

dehrmann 11mo ago
But that's it's thing. C++ with improved syntax (think Kotlin for C++) isn't really enough to gain popularity. It's like how Dvorak is sorta better than qwerty, but it doesn't offer anything new, and it isn't so much better it justifies migrating.
- pwdisswordfishy 11mo ago
  No need to imagine hypotheticals – this exists: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront

TuxSH 11mo ago

> Unnecessarily over-complicated. Most of the complexity comes from the fact that C++ trivially supports consuming most C code, but with its own lifetime model on top, and that it also offers great flexibility. Of course things become simpler when you ditch C source compat and can just declare "this variable will not be aliased by anyone else" AFAIK C++'s constexpr and TMP is less limited than Rust's is.

pjmlp 11mo ago
Also, with all its warts, I find easier to stay within C++ itself, instead of two macro systems, that additionally depend on an external crate.

wrathofmonads 11mo ago

The real barrier is the C++ ecosystem. It represents the cost of losing decades of optimized, highly integrated, high-performance libraries. C++ maps almost perfectly to the hardware with minimal overhead, and it remains at the forefront of the AI revolution. It is the true engine behind Python scientific libs and even Julia (ex. EnzymeAD). Rust does not offer advantages that would meaningfully improve how we approach HPC. Once you layer the necessary unsafe operations, C++ code in practice becomes mostly functional and immutable, and lifetimes matter less beyond a certain threshold when building complex HPC simulations. Or even outsourced to a scripting layer with Python.

amluto 11mo ago
> C++ maps almost perfectly to the hardware with minimal overhead Barely. The C++ aliasing rules map quite poorly into hardware. C++ barely helps at all with writing correct multithreaded code, and almost all non-tiny machines have multiple CPUs. C++ cannot cleanly express the kinds of floating point semantics that are associative, and SIMD optimization care about this. C++ exceptions have huge overhead when actually thrown.
- wrathofmonads 11mo ago
  In simulations or in game dev, the practice is to use an SoA data layout to avoid aliasing entirely. Job systems or actors are used for handling multithreading. In machine learning, most parallelism is achieved through GPU offloading or CPU intrinsics. I agree in principle with everything you’re saying, but that doesn’t mean the ecosystem isn’t creative when it comes to working around these hiccups.
- jcalvinowens 11mo ago
  > The C++ aliasing rules map quite poorly into hardware. But how much does aliasing matter on modern hardware? I know you're aware of Linus' position on this, I personally find it very compelling :) As a silly little test a few months ago, I built whole Linux systems with -fno-strict-aliasing in CFLAGS, everything I've tried on it is within 1% of the original performance.

feelamee 11mo ago

I think rust has a lot of slippery points too. And this number will grow with years. So, yes - rust made a lot of good choices over C++, but this does not mean it has no its own problems. Therefore I can't say Rust is simple in this sense.. But, of course, this is a good evolution step.