Alignment between Carbon and C#?

[jeffrey-chongsathien]

I could imagine a combination of { Carbon, C# } being as the closest to the "one language everywhere" solution (if Blazor ever stopped compiling to JavaScript). Low/high level, native/web (cross OS)... and if the laughable dream of { engineers, corporations, governments } working together to simplify technology stacks ever happened, automated transpilers could drive consolidation.

With that unrealistic scenario in mind, and without any specifics to offer, does it make sense to design the language with one eye on aligning somewhat with C#?

[chandlerc]

First, I think the term "alignment" between languages isn't precisely defined. I can at least give how I would define it: trying to align the design patterns and idioms of two languages so that both developers feel a high degree of familiarity when moving between them. This can potentially extend to trying to have idiomatic interop and even migration of code between them, although it doesn't always.

Personally, I think it's difficult, if not impossible, to equally prioritize aligning a language with more than one other language -- whenever the two diverge, you end up really needing to make a choice. In Carbon, we try to make these kinds of language design choices based on a relatively consistent set of values and priorities. Inevitably, that leads your design to align with one language significantly more than the other.

For Carbon, we have a clearly stated priority here: we're trying to align with existing, large-scale C++ codebases as much as possible while enabling key improvements to the language from scalability to the introduction of memory safety. That has to remain our top priority in design.

We could consider trying to additionally align with another language, but at a second priority. However, the more we invest in this second priority, to an extent the more we distract ourselves from our top priority. We would need a huge motivation to do this, and I don't see that currently for many other languages (this isn't really specific to C# at all). The only case where I think there is a good secondary priority for us is around Rust and memory safety to ensure we can have high quality safe interop between strictly memory safe Carbon and Rust.

However, there are definitely cases where we have a relatively unconstrained language design decision. For these, we routinely look at other languages including C# to see if they have good patterns we can follow. We should definitely keep doing that, and definitely include C# when doing that.