[pciexpgpu]

I wonder how this compares with Carbon -> C++ [0].

Carbon is (was?) a fantastic proposal, but not sure if it has lost steam since it was introduced or how well it is being adopted (be it inside Google or outside)?

Being able to incrementally/interchangeably use/call existing C++ code (and vice versa) seems like a great design choice (in Carbon) without having to introspect the actual generated code.

Not sure how easy it is to get the cppfront-generated C++ to bridge with existing C++ code (and vice versa)?

[0] https://github.com/carbon-language/carbon-lang

[nindalf]

The roadmap for Carbon [0] mentions wanting to have basic, non-trivial programs written in Carbon by the end of 2024. They're aiming for a v0.1 release in 2025. If it gains traction, they're aiming for a v1.0 beyond 2027.

I don't think anyone outside Google will seriously adopt this before it reaches v1.0. Even within Google, they may choose other options.

[0] - https://github.com/carbon-language/carbon-lang/blob/trunk/do...

[bluGill]

Googles habit of dropping support for useful things make me not willing to trust them. I plan for my current code to be in use for at least 20 more years (i plan to retire before then), I don't want to explain to my boss either why we are maintaining a compiler or why we must rewrite working code.

[jokoon]

Herb Sutter briefly talked about why carbon was not a good contender, and I think remembering it was because of backward compatibility with C++.

At some point, keeping C++ semantics matters, since having different semantics would obviously prevent using previous C++ codebases, or make it more difficult to make those work together, and that may be why Carbon may not be a good choice.

[mort96]

Carbon isn't "being adopted", it's still being developed. Making a programming language takes time. Let them at least get to a point where they release some form of public beta (i.e a few more years, at least) before talking about adoption.

[chandlerc1024]

+100 btw. =D