"Successor languages": C++ - > Google's Carbon-lang, MATLAB -> Julia?

My take on it C++ needs to be replaced, just with what, Julia, other existing language? Or this new one:

See full list here: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md#language-goals-and-priorities

We are designing Carbon to support:

  • Performance-critical software
  • Software and language evolution
  • Code that is easy to read, understand, and write
  • […]
  • Interoperability with and migration from existing C++ code

Many languages share subsets of these goals, but what distinguishes Carbon is their combination. Where it is necessary to make tradeoffs between these goals, we intend to prioritize them in this order.
[…]
No need for a lower level language. Developers should not need to leave the rules and structure of Carbon, whether to gain control over performance problems or to gain access to hardware facilities.

Github has tons of docs on it, but if you want the official video:

A short 3 min. summary here: https://www.youtube.com/watch?v=QRUK9ylS4ho

John Carmack on languages: https://youtu.be/RfWGJS7rckk?t=377

Sometimes I wish for this in Julia:

3 Likes

Why would someone use Carbon instead of C++20? Seems they just released Carbon too late.

Wouldn’t be surprised if the Carbon developers still think of C++14 when they say “modern C++”.

Well the ship has sailed on that one. :slight_smile: But you can choose to only use ASCII in your own code (just as Python, and I think still C++, forces you to use for identifiers), if I recall, no (exported) function of a package should be non-ASCII, according to some style-guide, so I think the issue is overblown. I like π and ℯ and e.g. ⊻ but nobody is forced to use, you always have ASCII equivalent; for all operators except that last one, then the ASCII-only in functional form.

Carbon standardized on UTF-8 for source code (including allowing non-ASCII for identifiers excluding identifiers, then ASCII), and supports well in general, but that’s the least surprising or interesting/innovative part of the language design.

Some trivia, C++ (and also C?) is not portable (despite C/C++ often claimed very portable), for any program including simplest: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2295r4.pdf

Abstract
We propose that UTF-8 source files should be supported by all C++ compilers. […]
Motivation
Even this simple program cannot be written portably in C++ and may fail to
compile:
int main() {}
— Beman Dawes

That’s because even with all the major compilers supporting, and some only, UTF-8, I guess some compiler could be expecting say EBCDIC.

For non-source code there’s:

1 Like

A.
Because C++ is too complex? And its standard library speed not as fast as it could be, because of its stable ABI: Reddit - Dive into anything

There is no question that libstdc++'s implementation of <regex> is not well optimized. But there is more to it than that. It’s not that the standard requirements inhibit optimizations so much as the standard requirements inhibit changes.
[…]
The minute libstdc++ (and other standard library implementations) started shipping an implementation of C++ regular expressions, they bound themselves to a specific implementation that could not be changed in a way that impacted the ABI of the library. And while they could cause another ABI break to fix it, standard library implementers don’t like breaking ABI because people don’t upgrade to standard libraries that break their code.

When C++11 forbade basic_string copy-on-write implementations, libstdc++ had an ABI problem.

It’s intriguing to contrast Carbon with (C++), Julia, Rust, Zig, how it’s template/generics system diverges from C++ and Julia, also its error model. I can’t see that Cabon has multiple dispatch (or multimethods), even though Strostrup proposed for C++, or are “mixins” the same, or similar enough:

For example, mixins for implementation reuse and generics for separating interface from implementation. This allows Carbon to move away from multiple inheritance, which doesn’t have as efficient of an implementation strategy.

Classes by default are final

It’s intriguing to look at the goals; and non-goals, e.g. “Stable language and library ABI”, because C++ has a stable ABI, and it’s holding C++ back, meaning its standard library can’t be fastest.

See FAQ: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md

Why not improve C++?

A lot of effort has been invested into improving C++, but C++ is difficult to improve.

For example, although P2137 was not accepted, it formed the basis for Carbon’s goals.

Why not fork C++?

[…]

Why not Rust?

If you can use Rust, ignore Carbon

please see Carbon’s success criteria.

See: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/goals.md

Goals

[…]

Software and language evolution

[…]
Be mindful of legacy. Globally, there may be as many as 50 billion lines of C++ code. Any evolution of Carbon that fails to account for human investment/training and legacy code, representing significant capital, is doomed from the start. […]
Support software outside of the primary use cases well. There are surprisingly high costs for developers to switch languages. […]
All unsafe or risky operations and interfaces must support some dynamic checking.
[…]
Syntax should parse with bounded, small look-ahead. Syntax that requires unbounded look-ahead or fully general backtracking adds significant complexity to parsing and makes it harder to provide high quality error messages. The result is both slower iteration and more iterations, a multiplicative negative impact on productivity. Humans aren’t immune either; they can be confused by constructs that appear to mean one thing but actually mean another. Instead, we should design for syntax that is fast to parse, with easy and reliable error messages.[…]

Interoperability with and migration from existing C++ code

[…]
We must be able to move existing large C++ codebases – some with hundreds of millions of lines of code and tens of thousands of active developers – onto Carbon. […]

Automated source-to-source migration of large segments of large-scale idiomatic C++ code bases with high fidelity. […]

Support for bi-directional interoperability with existing C++ code. We need Carbon code to be able to call into C and C++ libraries with both reasonable API clarity and high performance. […]

Non-goals

There are common or expected goals of many programming languages that we explicitly call out as non-goals for Carbon. […]

Stable language and library ABI

We would prefer to provide better, dedicated mechanisms to decompose software subsystems in ways that scale over time rather than providing a stable ABI across the Carbon language and libraries. Our experience is that providing broad ABI-level stability for high-level constructs is a significant and permanent burden on their design. It becomes an impediment to evolution, which is one of our stated goals. […]

Backwards or forwards compatibility

I can’t see that this language has multiple dispatch (or multimethods), even though Strostrup proposed for C++.

Error (not exception) handling: https://github.com/carbon-language/carbon-lang/blob/075b3aba1bdbcb26488529fe35778981d219e5ca/docs/project/principles/error_handling.md

Carbon errors, unlike exceptions in C++ and similar languages, will not be propagated implicitly. Instead, Carbon will very likely need to provide some explicit but syntactically lightweight means of propagating errors, such as Rust’s ? operator

B.
I believe the developers of the language are very well aware of C++20, and probably have it or C++23 in mind with “modern C++”; they at least mention C++20 is several places, in the docs, e.g.

Interoperability will target C++17. Any interoperability support for future versions of C++, including features such as C++20 modules, will be based on a cost-benefit analysis.

and: https://github.com/carbon-language/carbon-lang/blob/075b3aba1bdbcb26488529fe35778981d219e5ca/proposals/p0142.md

Characters in identifiers and whitespace

We will largely follow Unicode Annex 31 in our selection of identifier and whitespace characters. […]
For example, this list includes U+30EA (KATAKANA LETTER RI), but not U+2603 (SNOWMAN), both of which are permitted in identifiers in C++20. […]
we should use Annex 31 as a basis for our decisions, and should expect strong justification for deviations from it.

Note that this aligns with the current direction for C++, as described in WG21 paper P1949R6.

1 Like

Your analogy is flawed. Julia isn’t the successor language to matlab because you can’t just take a matlab lib and link it in a julia program. That’s the criterium the authors of Carbon set for a successor language. Examples:
C → C++
Java → Kotlin
Objective C → Swift
C++ → Carbon

2 Likes

Yes, Julia only has similar syntax to MATLAB and trying to be a replacement but not fully compatible. But neither is Kotlin (and even C++ isn’t a strict superset to C), but you CAN call to and from MATLAB. Then it’s not a successor in the sense you still need to buy the MATLAB license. But that’s not an issue calling its clone Octave, as I have.