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.
> 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.
> 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.
Python and Perl were not backwards compatible with anything when they were released.
Perl 5 (and older) was highly backwards compatible from a programmer standpoint. Much of Perl is an agglomeration of preexisting Unix command line tools and little languages into one language.
Well, it's closest semantically to awk, but awk is not syntactically compatible with Perl [1]. That's pretty similar to the situation with Rust and C++: semantically compatible but not syntactically compatible.
Definitely it'd be interesting. But I feel like such a thing is going to have the same issues I worry about with the ISO Core C++ lifetime checker: existing C++ code just isn't designed for lifetimes, so you will have to rework the logic a lot to get the static analysis to pass. When you have that much manual intervention, I wonder whether you're porting or really just rewriting—and if you're rewriting, syntactic compatibility doesn't matter so much.
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.