3 ms·

This immediately suggests what you want is a gradual migration process from one language through several intermediate languages to your target language. i.e. i

This immediately suggests what you want is a gradual migration process from one language through several intermediate languages to your target language. i.e. instead of a big bang C++ -> Carbon migration, instead you want something like: C++ -> C+++ -> Carbon-- -> Carbon -> Carbon++ -> Rust (Basically fake names for more gradual transitional intermediate languages, assuming Google would like to have everything in Rust eventually.) The key idea of "targeting automated migrations" makes this kind of thing feasible

Mond_ 2y ago
Yup! I didn't work this into the post, but this is in fact exactly (more or less) the goal. Chandler even explicitly says "Maybe we can eventually convert some future version of Carbon to Rust, who knows." Whether that is going to happen (or is viable) is unclear for now, but it's pretty clear that a migration of C++ to (idiomatic) Carbon will probably involve at least a few steps.
IshKebab 2y ago
That's not really possible. Rust isn't "C++ but better". It has several design decisions that make it not really compatible with C++, e.g. no move constructors & the use of fat pointers.
- habitue 2y ago
  I think I'd say "it's hard, and would require making some opinionated decisions as to what to convert something to" vs "not possible". The bar is pretty high for "not possible"
- zozbot234 2y ago
  The main obstacle to making Rust a "C++ but better" language is arguably the half-baked design of its support for pinned data. (Because "pinned", i.e. location-sensitive objects that can't simply be memcpy'd elsewhere are ubiquitous in idiomatic C/C++.) But there are several language proposals to mitigate this in the future, though for most of these a full transition will require an edition change in order not to break backward-compat. As for the use of 'fat' vs. 'thin' pointers for dynamic dispatch, a C++-style vtable ptr is just a &'static VTableStruct, where VTableStruct is a dictionary of functions. The anyhow crate is a good example of how you can implement that particular approach.

Mond_ 2y ago

Yup! I didn't work this into the post, but this is in fact exactly (more or less) the goal. Chandler even explicitly says "Maybe we can eventually convert some future version of Carbon to Rust, who knows." Whether that is going to happen (or is viable) is unclear for now, but it's pretty clear that a migration of C++ to (idiomatic) Carbon will probably involve at least a few steps.

IshKebab 2y ago

That's not really possible. Rust isn't "C++ but better". It has several design decisions that make it not really compatible with C++, e.g. no move constructors & the use of fat pointers.

habitue 2y ago
I think I'd say "it's hard, and would require making some opinionated decisions as to what to convert something to" vs "not possible". The bar is pretty high for "not possible"
zozbot234 2y ago
The main obstacle to making Rust a "C++ but better" language is arguably the half-baked design of its support for pinned data. (Because "pinned", i.e. location-sensitive objects that can't simply be memcpy'd elsewhere are ubiquitous in idiomatic C/C++.) But there are several language proposals to mitigate this in the future, though for most of these a full transition will require an edition change in order not to break backward-compat. As for the use of 'fat' vs. 'thin' pointers for dynamic dispatch, a C++-style vtable ptr is just a &'static VTableStruct, where VTableStruct is a dictionary of functions. The anyhow crate is a good example of how you can implement that particular approach.