It's not that it isn't gaining traction. Rather it's just a massive, herculean undertaking that Sean and co have been working on in the background. Hell Sean only just a few months ago started posting demos on twitter of their C++ borrow checker proof of concept finally working in moderately non-trivial examples.
This isn't to say that their progress isn't going well. Rather they've been making incredible progress at a rate nobody really thought possible but this is just a truly Herculean effort.
Also this proposal is literally only 2 days old. The work has been in progress for years but this is to my knowledge the first time it has actually been proposed formally.
This is correct. Sean has been working for something like two years implementing these ideas to make sure they’re feasible, and only recently turned to actual advocacy for them, now that the experiment appears successful.
Because C++ is big and old and everyone wants it to be something different. Functional programmers want it to be more functional, OOP developers want more object oriented, etc. And the syntax must look familiar. And everything must be backwards-compatible and all older legacy code needs to work fine. And it must have next-to-no runtime cost. Etc.
Making any changes to C++ is a slow process - as it is for any older and larger language.
Plus...I think memory safety is a pretty low priority area for C++, frankly. It's harder to shoehorn in at this point, C++ has never prioritized it over raw performance or flexibility.
Why was this downvoted? It's not just another generic "rewrite it in Rust" comment. I was making a specific point that incremental rewrites of existing C++ code are very possible in Rust. And that process would not be that different from rewriting the code in a "safe" dialect of C++.
If it makes you feel better you can rename the Rust language to "C++2.0" but the rewrite process itself will be the same in both cases. You keep expanding the amount of safe code you have within the codebase over time, one module at a time.
Your first sentence comes across as incredibly combative, and not everyone agrees. Personally, that's why I downvoted it. It would be a much better comment if it was the same thing without it.
For example, one advantage of this strategy as opposed to an incremental Rust re-write is that you would retain a single toolchain, whereas that would require having two.
Yes, it's an extension to C++, so as it is implemented now in Circle, and as it would be if it were to be standardized, it would be part of the regular toolchain.
C++ is a very slow moving language. There are various rumblings about making it memory safe, but if we get a proper memory safe C++ it'll probably be in the '30s.
