4 ms·

>In the meantime C++ has evolved. I cant remember the last time I had an uninitialized memory, null pointers, or buffer overflow -bug. Those are low level C pro

>In the meantime C++ has evolved. I cant remember the last time I had an uninitialized memory, null pointers, or buffer overflow -bug. Those are low level C problems. If you avoid C-style programming and stick with modern C++ (RAII, value semantics, STL, boost, etc) you wont get them. While your small walled garden within C++14 is nice, clean, safe, and well maintained. Massive parts of it are built ON THE VERY FOUNDATIONS YOU ARE ATTEMPTING To AVOID. This is the irony of C++. While there is a very nice subset of the language, that does nearly all the same things Rust does. You still have 30 years of legacy laying around. You likely won't find a job that EXCLUSIVELY follows the C++14 guidelines. You WILL have to learn the legacy patterns, and work with legacy code, and make legacy mistakes. >C++ is 35 years old. It has stood the test of time. I would not be surprised if it was still popular in 35 years time, when I retire. There is so much C++ infrastructure code in this world, that its not going anywhere. I don't debate this fact. But legacy C code never stood in the way of C++'s adoption. There are always gonna be MORE programmers tomorrow, then today. People adopting a language is hardly a zero sum game.

daveguy 11y ago
On the plus side 30 years of legacy laying around also includes a lot of mature and well maintained libraries.
- valarauca1 11y ago
  Which don't follow the much professed C++14 guidelines and can introduce the errors that Rust is designed to prevent. :.:.: I don't have an issue with C++ itself, its just the meme that "C++14 will solve all of C++'s problems". It won't. C++'s problems are now locked in, and fixed. They've been known for 25-30 years, and we'll deal with them for another 50+. Yes the tooling is great, there are amazing libraries, there is still virtual templated necromancy, there are still null pointers, and use after frees. There still will be tomorrow, and there still will be in 50 years.
gpderetta 11y ago
> [...] This is the irony of C++. While there is a very nice subset of the language, that does nearly all the same things Rust does. You still have 30 years of legacy laying around. You likely won't find a job that EXCLUSIVELY follows the C++14 guidelines. You WILL have to learn the legacy patterns, and work with legacy code, and make legacy mistakes. Large existing codebases are a strength of C++ though. Any new replacement language won't magically make those codebases go away. > [...] But legacy C code never stood in the way of C++'s adoption. There are always gonna be MORE programmers tomorrow, then today. People adopting a language is hardly a zero sum game. The killer feature of C++ was the seamless interoperability with C which allowed trivial use of C libraries, and, most importantly, easy piecemeal evolution of large C codebases. For example GCC is begin ported to C++ with relative ease, while a rewrite in rust would be a significantly more complex endeavor. Then again, beyond lifetime checking, rust and C++ are very similar languages and seamless interoperability is not inconceivable. I believe that's the missing feature for rust to achieve world domination.
- valarauca1 11y ago
  >Large existing codebases are a strength of C++ though. Any new replacement language won't magically make those codebases go away. Which I already said... >>I don't debate this fact. But legacy C code never stood in the way of C++'s adoption. There are always gonna be MORE programmers tomorrow, then today. People adopting a language is hardly a zero sum game. >For example GCC is begin ported to C++ with relative ease, while a rewrite in rust would be a significantly more complex endeavor. Source or opinion? >Then again, beyond lifetime checking, rust and C++ are very similar languages and seamless interoperability is not inconceivable. I believe that's the missing feature for rust to achieve world domination. No I agree. Seemless importing with C++ would be amazing. Name mangling in C++ is just a bit of an issue. Rust works great with C. The FFI is very stable. I use Rust libraries at work as generating 32bit DLL's is possible with nightly.
- dikaiosune 11y ago
  I haven't used it yet, but Rust supposedly works very well with C libraries, both calling into them and being called from them.
blub 11y ago
I've read your replies and I think you're arguing too passionately and missing facts. It doesn't matter that there's much legacy C++ code. Two things will happen: a) it will stay C++03, regardless of what changes in C++ or what other languages pop up. This kind of code is probably part of a working product which fulfills its mission and maybe gets small updates or fixes. b) it will continue to be maintained, and it will be able to benefit from some or most of the changes coming in new C++ versions. It doesn't mean that it will be converted to super duper C++14, but that's not how software maintenance works anyway! And guess what, they probably won't be converted to Rust either, but they will be better due to the new standards. You are building a strawman when claiming that it's either Rust or failing to use pure C++14. Successful software tools offer backwards compatibility when making improvements and iterate instead of replacing everything. Just ask the Python and Perl teams. And this is how C++ was able to build marketshare, by offering a transition path from C. What exactly is that path for C++ to Rust, rewriting everything? Finally, new projects will use the new standards. My current project is C++11. The next one will be C++14 and we will absolutely make use of the new features where it makes sense.
- pcwalton 11y ago
  > And guess what, they probably won't be converted to Rust either, but they will be better due to the new standards. What we need is memory safety, and new standards don't provide that. Maybe in the future they will, but I have significant questions about how suitable the ISO Core C++ lifetime checker will be. > Just ask the Python and Perl teams. Python and Perl were not backwards compatible with anything when they were released. Rust is not a new version of C++. It is a new language. > And this is how C++ was able to build marketshare, by offering a transition path from C. What exactly is that path for C++ to Rust, rewriting everything? No. It's a very comprehensive FFI, IMO among the best in any language. We even have (preliminary, quite hacky) C++ support. We had to spend time developing this, because we actually use Rust for Servo and we had to develop incrementally, retaining large C++ components. It works great.
  - kbenson 11y ago
    >> Just ask the Python and Perl teams. > Python and Perl were not backwards compatible with anything when they were released. I think the implication is that the teams will tell you that the upgrades to Python 3 and Perl 6 were problematic because they didn't offer backwards compatibility. If so, it's a bit silly, because the point of those upgrades was to advance the languages beyond would could be done with backwards compatible iteration. Asking the teams would probably yield a bunch of people that were adamant that the decision was sound, and it needed to be done, but there were missteps in execution. Asking the communities would likely yield a more polarized set of opinions. That said, IMO using either of these items as examples to bolster an argument is almost always a mistake, since their own discussions are so large and polarizing, they rarely ever make make a point more clear.

daveguy 11y ago

On the plus side 30 years of legacy laying around also includes a lot of mature and well maintained libraries.

valarauca1 11y ago
Which don't follow the much professed C++14 guidelines and can introduce the errors that Rust is designed to prevent. :.:.: I don't have an issue with C++ itself, its just the meme that "C++14 will solve all of C++'s problems". It won't. C++'s problems are now locked in, and fixed. They've been known for 25-30 years, and we'll deal with them for another 50+. Yes the tooling is great, there are amazing libraries, there is still virtual templated necromancy, there are still null pointers, and use after frees. There still will be tomorrow, and there still will be in 50 years.

gpderetta 11y ago

> [...] This is the irony of C++. While there is a very nice subset of the language, that does nearly all the same things Rust does. You still have 30 years of legacy laying around. You likely won't find a job that EXCLUSIVELY follows the C++14 guidelines. You WILL have to learn the legacy patterns, and work with legacy code, and make legacy mistakes. Large existing codebases are a strength of C++ though. Any new replacement language won't magically make those codebases go away. > [...] But legacy C code never stood in the way of C++'s adoption. There are always gonna be MORE programmers tomorrow, then today. People adopting a language is hardly a zero sum game. The killer feature of C++ was the seamless interoperability with C which allowed trivial use of C libraries, and, most importantly, easy piecemeal evolution of large C codebases. For example GCC is begin ported to C++ with relative ease, while a rewrite in rust would be a significantly more complex endeavor. Then again, beyond lifetime checking, rust and C++ are very similar languages and seamless interoperability is not inconceivable. I believe that's the missing feature for rust to achieve world domination.

valarauca1 11y ago
>Large existing codebases are a strength of C++ though. Any new replacement language won't magically make those codebases go away. Which I already said... >>I don't debate this fact. But legacy C code never stood in the way of C++'s adoption. There are always gonna be MORE programmers tomorrow, then today. People adopting a language is hardly a zero sum game. >For example GCC is begin ported to C++ with relative ease, while a rewrite in rust would be a significantly more complex endeavor. Source or opinion? >Then again, beyond lifetime checking, rust and C++ are very similar languages and seamless interoperability is not inconceivable. I believe that's the missing feature for rust to achieve world domination. No I agree. Seemless importing with C++ would be amazing. Name mangling in C++ is just a bit of an issue. Rust works great with C. The FFI is very stable. I use Rust libraries at work as generating 32bit DLL's is possible with nightly.
dikaiosune 11y ago
I haven't used it yet, but Rust supposedly works very well with C libraries, both calling into them and being called from them.

blub 11y ago

I've read your replies and I think you're arguing too passionately and missing facts. It doesn't matter that there's much legacy C++ code. Two things will happen: a) it will stay C++03, regardless of what changes in C++ or what other languages pop up. This kind of code is probably part of a working product which fulfills its mission and maybe gets small updates or fixes. b) it will continue to be maintained, and it will be able to benefit from some or most of the changes coming in new C++ versions. It doesn't mean that it will be converted to super duper C++14, but that's not how software maintenance works anyway! And guess what, they probably won't be converted to Rust either, but they will be better due to the new standards. You are building a strawman when claiming that it's either Rust or failing to use pure C++14. Successful software tools offer backwards compatibility when making improvements and iterate instead of replacing everything. Just ask the Python and Perl teams. And this is how C++ was able to build marketshare, by offering a transition path from C. What exactly is that path for C++ to Rust, rewriting everything? Finally, new projects will use the new standards. My current project is C++11. The next one will be C++14 and we will absolutely make use of the new features where it makes sense.

pcwalton 11y ago
> And guess what, they probably won't be converted to Rust either, but they will be better due to the new standards. What we need is memory safety, and new standards don't provide that. Maybe in the future they will, but I have significant questions about how suitable the ISO Core C++ lifetime checker will be. > Just ask the Python and Perl teams. Python and Perl were not backwards compatible with anything when they were released. Rust is not a new version of C++. It is a new language. > And this is how C++ was able to build marketshare, by offering a transition path from C. What exactly is that path for C++ to Rust, rewriting everything? No. It's a very comprehensive FFI, IMO among the best in any language. We even have (preliminary, quite hacky) C++ support. We had to spend time developing this, because we actually use Rust for Servo and we had to develop incrementally, retaining large C++ components. It works great.
- kbenson 11y ago
  >> Just ask the Python and Perl teams. > Python and Perl were not backwards compatible with anything when they were released. I think the implication is that the teams will tell you that the upgrades to Python 3 and Perl 6 were problematic because they didn't offer backwards compatibility. If so, it's a bit silly, because the point of those upgrades was to advance the languages beyond would could be done with backwards compatible iteration. Asking the teams would probably yield a bunch of people that were adamant that the decision was sound, and it needed to be done, but there were missteps in execution. Asking the communities would likely yield a more polarized set of opinions. That said, IMO using either of these items as examples to bolster an argument is almost always a mistake, since their own discussions are so large and polarizing, they rarely ever make make a point more clear.