Comment by IshKebab
3 days ago
> being workshopped with the C++ community
Honestly seems like a dubious idea. The C++ community that remains are even more "just get good" than before. They still think UB all over the place is fine.
3 days ago
> being workshopped with the C++ community
Honestly seems like a dubious idea. The C++ community that remains are even more "just get good" than before. They still think UB all over the place is fine.
I think that might be true of the language committee, but there's presumably a huge crowd of people with existing c++ code bases that would like to have a different path forward than just hoping that the committee changes priorities.
That is what many of us have done moving into managed languages, with native libraries when required to do so.
The remaining people driving where the language goes have other priorities in mind like reflection.
The profiles that were supposed to be so much better than the Safe C++ proposal, none of them made it into C++26, and it remains to be seen if we ever will see a sensible preview implementation for C++29.
C++ 26 doesn't have the technology, but it wouldn't matter anyway because what's crucial about Rust isn't the technology it's the culture.
If WG21 were handling Rust instead f64 would implement Ord, and people would just write unsafe blocks with no explanation in the implementation of supposedly "safe" functions. Rust's technology doesn't care but their culture does.
Beyond that though, the profiles idea is dead in the water because it doesn't deliver composition. Rust's safety composes. Jim's safe Activity crate, Sarah's safe Animals crate and Dave's safe Networking crate compose to let me work with a safe IPv6-capable juggling donkey even though Jim, Sarah and Save have never met and had no idea I would try that.
A hypothetical C++ 29 type safe Activity module, combined with a thread safe Animals module, and a resource leak safe Networking module doesn't even get you something that will definitely work, let alone deliver any particular safety.
7 replies →
I'd say the C++ community is torn.
Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety.
Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project.
Video game companies on the other hand are likely to be in the latter camp. Most of the times, security is not as critical, especially for offline games, and memory corruption usually don't go further than a game crash. Tight memory management however is critical, and it often involves raw pointers and custom allocation schemes.
I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability".
Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance on intentionally losing the performance competition.
Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages?
A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust.
There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common.
(Maybe Rust could do this, but they haven't stabilized their ABI yet, and I don't the details.)
[0]: https://faultlore.com/blah/c-isnt-a-language/
6 replies →