3 ms·

Like C always will, C++ mostly still echoes the diversity of hardware architectures and runtime environments out there. That diversity is still broader than man

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.
- pjmlp 11mo ago
  SFINAE in 2025 is only reasonable in existing old code, or people stuck in old compilers. Since C++17 there are better options. Despite all its warts, most C++ wannabe replacements, depend on compiler tools written in C++, and this isn't going to change in then foreseeable future, based on the about two decades that took to replace C with C++ in compiler development circles, even though there is some compatibility.

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.

pjmlp 11mo ago
SFINAE in 2025 is only reasonable in existing old code, or people stuck in old compilers. Since C++17 there are better options. Despite all its warts, most C++ wannabe replacements, depend on compiler tools written in C++, and this isn't going to change in then foreseeable future, based on the about two decades that took to replace C with C++ in compiler development circles, even though there is some compatibility.