5 ms·

> do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new featu

by saghm 1y ago

> do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? This is an interesting perspective to me, because my view as someone who's been using Rust since close to 1.0 and hasn't done much more than dabbled in C++ over the years is basically the opposite. My (admittedly limited) understanding is that this has never really been a goal of the committee, because if someone is willing to sacrifice backwards compatibility, they could presumably just switch to using one of those other languages at that point. Arguably the main selling point of C++ today is the fact that there's a massive set of existing codebases out there (both libraries that someone might want to use and applications that might still be worked on), and for the majority of them, being rewritten would be at best a huge effort and more realistically not something going to be seriously considered. If the safety and ergonomics of C++ are a concern, I guess I'm not sure why someone would pick it over another language for a newly-started codebase. In terms of safety, Rust is an option that exists today without needing C++ to change. Ergonomics are a bit less clear-cut, but I'd argue that most of the significant divergences in ergonomics between languages are pretty subjective, and it's not obvious to me that there's a significant enough gap in between Rust's and C++'s respective choices that warrant a new language that's not compatible with C++ but is far enough from Rust for someone to refuse to use it on the basis ergonomics alone. It seems to me like "close enough to C++ to attract the people who don't want to use Rust but far enough from Rust to justify breaking C++'s backwards compatibility" is just too narrow a niche for it to be worth it for C++ to go after.

ratmeadow 1y ago
It's true that without backwards compatibility concerns, Rust looks like a great alternative. However I think C++ still has some things going for it which may make it a useful option, assuming the core issues were fixed. C++ gives ultimate control over memory and low level things (think pointers, manual stack vs heap, inline assembly). It has good compatibility with C ABIs. It's very general purpose and permissive. And there are many programmers with C++ (or C) knowledge out there already. Further, I think C++ started on its current feature path before Rust really got a big foothold. Consider C++ has been around a really long time, plenty long enough to fix core features. Finally I reckon the whole backwards compatibility thing is a bit weird because if the code is so ancient and unchangable, why does it need the latest features? Like you desprately need implicit long-to-int conversion but also coroutines?? And for regular non-ancient code, we already try to avoid the problematic parts of C++, so fixing/removing/changing them wouldn't be so bad. IMO it's a far overdone obsession with backwards compatibility. Of course without a significant overhaul to the language you'd probably say "screw it" and start from scratch with something nicer like Rust.
- saghm 1y ago
  I think I might be getting confused about the point you're making here. To me, pre-existing knowledge and the decades-long legacy of C++ feel like much stronger arguments against changing anything in a breaking way compared to making breaking changes to improve the language. I do agree with you around a lot of the new features being introduced not feeling super necessary, but I'm guessing that the stance of people in favor of them is that adding them doesn't feel like it's a huge problem either given that they can do them without breaking anything. My perception is that C++ has already been a fairly large language for a while, and that most codebases already develop a bit of a dialect of which features to use or not use (which you allude to as well), so I could imagine that they expect people who don't like the new features to just ignore them. I think I'm most confused about the last part that you're saying. A significant overhaul to the language in a breaking way feels pretty much the same as saying "screw it" and starting from scratch, just with specific ergonomic choices being closer to C++ than to Rust. Several of the parts that you cite as the strengths of the language, like inline assembly and pointers are still available in Rust, just not outside of explicitly unsafe contexts, and I'd imagine that an overhaul of C++ to enhance memory safety would end up needing to make a fairly similar compromise for them. It just seems like the language you're wishing for would end up with a fairly narrow design space, even if it is objectively superior to the C++ we have today, because it would have to give up the largest advantage that C++ does have without enough unoccupied room to grow into. The focus on backwards compatibility doesn't seem to be that it would necessarily be the best choice in a vacuum, but a reflection of the state of the ecosystem as it is today, and a perception that sacrificing it would be giving up its position as the dominant language in a well-defined niche to try to compete in a new one. This is obviously a subjective viewpoint, but it doesn't seem implausible to me, and given the fact that we can't really know how it would work out unless they do try, sticking with compatibility feels like the safer option.
  - dwattttt 1y ago
    The biggest question I have around the viability of breaking changes in C++ is whether you can compile some code with a newer breaking standard, some with an older standard, and link them. Headers would be a problem given their text inclusion in multiple translation units, but it's not insurmountable; you're currently limited to the oldest standard a header is included into, and under a new standard that breaks compatibility you'd be limited to a valid subset of the old & new standard. EDIT: ironically modules (as a concept) would (could?) solve the header problem, but they've not exactly been a success story so far.
tempodox 1y ago
With C++ I can use Qt to make a GUI app that builds and runs on macOS, Linux, and Windows. Is there anything even close to that for Rust?
- halfcat 1y ago
  There’s egui [0] [1] which, being immediate mode, simplifies state management quite a bit. Runs on Mac, Linux, Windows, Web, and mobile. [0] https://github.com/emilk/egui https://github.com/emilk/egui [1] https://www.egui.rs/ https://www.egui.rs/

by saghm 1y ago

ratmeadow 1y ago

It's true that without backwards compatibility concerns, Rust looks like a great alternative. However I think C++ still has some things going for it which may make it a useful option, assuming the core issues were fixed. C++ gives ultimate control over memory and low level things (think pointers, manual stack vs heap, inline assembly). It has good compatibility with C ABIs. It's very general purpose and permissive. And there are many programmers with C++ (or C) knowledge out there already. Further, I think C++ started on its current feature path before Rust really got a big foothold. Consider C++ has been around a really long time, plenty long enough to fix core features. Finally I reckon the whole backwards compatibility thing is a bit weird because if the code is so ancient and unchangable, why does it need the latest features? Like you desprately need implicit long-to-int conversion but also coroutines?? And for regular non-ancient code, we already try to avoid the problematic parts of C++, so fixing/removing/changing them wouldn't be so bad. IMO it's a far overdone obsession with backwards compatibility. Of course without a significant overhaul to the language you'd probably say "screw it" and start from scratch with something nicer like Rust.

saghm 1y ago
I think I might be getting confused about the point you're making here. To me, pre-existing knowledge and the decades-long legacy of C++ feel like much stronger arguments against changing anything in a breaking way compared to making breaking changes to improve the language. I do agree with you around a lot of the new features being introduced not feeling super necessary, but I'm guessing that the stance of people in favor of them is that adding them doesn't feel like it's a huge problem either given that they can do them without breaking anything. My perception is that C++ has already been a fairly large language for a while, and that most codebases already develop a bit of a dialect of which features to use or not use (which you allude to as well), so I could imagine that they expect people who don't like the new features to just ignore them. I think I'm most confused about the last part that you're saying. A significant overhaul to the language in a breaking way feels pretty much the same as saying "screw it" and starting from scratch, just with specific ergonomic choices being closer to C++ than to Rust. Several of the parts that you cite as the strengths of the language, like inline assembly and pointers are still available in Rust, just not outside of explicitly unsafe contexts, and I'd imagine that an overhaul of C++ to enhance memory safety would end up needing to make a fairly similar compromise for them. It just seems like the language you're wishing for would end up with a fairly narrow design space, even if it is objectively superior to the C++ we have today, because it would have to give up the largest advantage that C++ does have without enough unoccupied room to grow into. The focus on backwards compatibility doesn't seem to be that it would necessarily be the best choice in a vacuum, but a reflection of the state of the ecosystem as it is today, and a perception that sacrificing it would be giving up its position as the dominant language in a well-defined niche to try to compete in a new one. This is obviously a subjective viewpoint, but it doesn't seem implausible to me, and given the fact that we can't really know how it would work out unless they do try, sticking with compatibility feels like the safer option.
- dwattttt 1y ago
  The biggest question I have around the viability of breaking changes in C++ is whether you can compile some code with a newer breaking standard, some with an older standard, and link them. Headers would be a problem given their text inclusion in multiple translation units, but it's not insurmountable; you're currently limited to the oldest standard a header is included into, and under a new standard that breaks compatibility you'd be limited to a valid subset of the old & new standard. EDIT: ironically modules (as a concept) would (could?) solve the header problem, but they've not exactly been a success story so far.

tempodox 1y ago

With C++ I can use Qt to make a GUI app that builds and runs on macOS, Linux, and Windows. Is there anything even close to that for Rust?

halfcat 1y ago
There’s egui [0] [1] which, being immediate mode, simplifies state management quite a bit. Runs on Mac, Linux, Windows, Web, and mobile. [0] https://github.com/emilk/egui https://github.com/emilk/egui [1] https://www.egui.rs/ https://www.egui.rs/