What's a successor language? Is then Carbon a successor?

[manuel-rubio]

I was finding curious about the definition of successor language. The definition was made using comparisons but it's not clear if you don't know about the specifics. For example, in the case of Objective-C and Swift, it's clear that if Apple is the main use of this language, it's used mainly for developing for iOS and macOS and then Apple starts supporting Swfit, it's clear they considered that Swift is the successor for Objective-C language in their environments.

But for the rest of the cases, this is more complicated. For example, Kotlin. Kotlin is a superset of Java and it still depends on Java (maybe not in the future) but it's built in the same ecosystem and was thought like Carbon, to provide a clear and smooth migration from Java to Kotlin, BUT, there's not removing support for Java, there are companies and projects that are not contemplating the change to Kotlin and they are co-existent. Kotlin is not a successor to Java, is an alternative.

In the case of TypeScript is exactly the same. TypeScript is an option we can choose, or not. In the same way, if we choose Dart, Elm, or whatever other language that transpiles to JavaScript. JavaScript isn't going to disappear and therefore TypeScript isn't going to succeed JavaScript, it's an alternative.

Said that Carbon isn't going to be a successor for C++, it's going to be only an alternative. Even if it has traction and a lot of companies start using it, there's going still a lot of companies and professionals that aren't going to use it, they are going to stick with C++ and it's ok, the ecosystem is going to have an alternative and it's great.

[geoffromer]

We don't have a formal definition or anything, but the way I've been thinking about it is that a "successor language" is designed primarily for the same users and use cases as its predecessor language, and designed to integrate into the ecosystem of that predecessor language in order to make it easy for those users and use cases to migrate to the successor. I don't think of "successor language" as meaning that the predecessor will no longer be used -- if so, it wouldn't be a very useful term, because as far as I know that only happens in the very rare situations where a central authority is in a position to force everyone to switch languages, as Apple is doing with Swift.

In any event, you're certainly right that in this respect, Carbon is following the example of Kotlin and TypeScript rather than Swift: we have no interest in stopping anybody from using C++ if they want, and a lot of people will undoubtedly continue to use C++ even if the Carbon experiment is wildly successful.

[tkoeppe]

I wanted to comment on this in the past. I realize that there isn't an official interpretation of "successor language", but in my mind, the term was most useful in the context of the initial Carbon presentation, where it was used in contrast to the other kind of language, the "superset language", and both terms were only meant to describe the specific problem of evolving an existing ecosystem. They were not meant to be absolute terms that support some far-reaching conclusions.

The specific question was, "what do you do with a large ecosystem built on a language with shortcomings?" The two, mutually exclusive approaches given in the presentation were:

• Superset language: a new language in which programs written in the existing language are also valid, and adoption consists of switching the toolchain to the new language (and existing code continues to be usable). Examples: C++ for C, Objective-C for C, TypeScript for JavaScript.
• Successor language: a new language that is independent and makes no attempt at any form of source compatibility. Adoption consists of adding the toolchain for the new language to the ecosystem, and the successor language is designed to be able to reuse and be reused by existing code at some other, non-source level, e.g. because certain build artefacts use a common architecture. Examples: Kotlin (interops with Java, both use the JVM), Swift (can reuse Obj-C libraries, interact with reference counting). Carbon would be of this kind, too.

In other words, I don't take "successor language" to mean that "Carbon will succeed C++", but rather only see it in context, in contrast with "superset language", and only in the context of this particular question of how to evolve an ecosystem. In particular, in this sense the existing C++ ecosystem is very much expected to stay around, and Carbon can be used primarily in cases where the existing limitations of C++ are significant for a particular project (or even just a piece of library).

[ZoeTarmeyqC]

Kotlin is a superset of Java, it still depends on Java (maybe it won't in the future), but it's built in the same ecosystem, like Carbon, to provide a clean and smooth transition from Java to Kotlin, but , it does not remove support for Java, there are companies and projects that do not consider switching to Kotlin, they coexist. Kotlin is not a successor to Java, but an alternative.