- Carbon goals | - Carbon and C++ | - Take a look | + Why? | + Goals | + Getting started | Join us
@@ -52,32 +50,114 @@ GitHub will autolink `img`, but won't produce a link when `href="#"`. - Batteries-included approach: compiler, libraries, docs, tools, package manager, and more -## Carbon goals +## Why build Carbon? -We believe Carbon must support: +C++ remains the dominant programming language for performance-critical software, +with massive and growing codebases and investments. However, it is struggling to +improve and meet developers' needs outlined above, in no small part due to +accumulating decades of technical debt. Incrementally improving C++ is +[extremely difficult](/docs/project/difficulties_improving_cpp.md), both due to +the technical debt itself and challenges with its evolution process. The best +way to address these problems is to avoid inheriting the legacy of C or C++ +directly, and instead start with solid language foundations like a +[modern generics system](#generics), modular code organization, and consistent, +simple syntax. -1. Performance-critical software -2. Software and language evolution -3. Code that is easy to read, understand, and write -4. Practical safety and testing mechanisms -5. Fast and scalable development -6. Modern OS platforms, hardware architectures, and environments -7. Interoperability with and migration from existing C++ code +Existing modern languages already provide an excellent developer experience: Go, +Swift, Kotlin, Rust, and many more. **Developers that _can_ use one of these +existing languages _should_.** Unfortunately, the designs of these languages +present significant barriers to adoption and migration from C++. These barriers +range from changes in the idiomatic design of software to performance overhead. + +Carbon is fundamentally **a successor language approach**, rather than an +attempt to incrementally evolve C++. It is designed around interoperability with +C++ as well as large-scale adoption and migration for existing C++ codebases and +developers. A successor language for C++ requires: + +- **Performance matching C++**, an essential property for our developers. +- **Seamless, bidirectional interoperability with C++**, such that a library + anywhere in an existing C++ stack can adopt Carbon without porting the rest. +- **A gentle learning curve** with reasonable familiarity for C++ developers. +- **Comparable expressivity** and support for existing software's design and + architecture. +- **Scalable migration**, with some level of source-to-source translation for + idiomatic C++ code. + +With this approach, we can build on top of C++'s existing ecosystem, and bring +along existing investments, codebases, and developer populations. There are a +few languages that have followed this model for other ecosystems, and Carbon +aims to fill an analogous role for C++: + +- JavaScript → TypeScript +- Java → Kotlin +- C++ → **_Carbon_** + +## Language Goals + +We are designing Carbon to support: + +- Performance-critical software +- Software and language evolution +- Code that is easy to read, understand, and write +- Practical safety and testing mechanisms +- Fast and scalable development +- Modern OS platforms, hardware architectures, and environments +- Interoperability with and migration from existing C++ code While many languages share subsets of these goals, what distinguishes Carbon is -their combination. For the Carbon project, they are prioritized in the above -order to help make clear what tradeoffs we intend to make. However, each and -every goal remains critically important: **Carbon _must_ have excellent C++ -interoperability and migration to be successful.** +their combination. -Read the [language overview](docs/design/) for more on the language design -itself, and the [goals](docs/project/goals.md) for more on these values. +We also have explicit _non-goals_ for Carbon, notably including: + +- A stable ABI for the entire language and library +- Perfect backwards or forwards compatibility + +Our detailed [goals](/docs/project/goals.md) document fleshes out these ideas +and provides a deeper view into our goals for the Carbon project and language. + +## Project status + +Carbon is currently an experimental project. We want to better understand +whether we can build a language that meets our successor language criteria, and +whether the resulting language can gather a critical mass of interest within the +larger C++ industry and community. + +Currently, we have fleshed out several core aspects of both Carbon the project +and the language: + +- The strategy of the Carbon Language and project. +- An open-source project structure, governance model, and evolution process. +- Critical and foundational aspects of the language design informed by our + experience with C++ and the most difficult challenges we anticipate. This + includes designs for: + - Generics + - Class types + - Inheritance + - Operator overloading + - Lexical and syntactic structure + - Code organization and modular structure +- A prototype interpreter demo that can both run isolated examples and gives a + detailed analysis of the specific semantic model and abstract machine of + Carbon. We call this the [Carbon Explorer](/explorer/). + +We are currently focused on getting more broad feedback and participation from +the C++ community, +[completing the 0.1 language design](/docs/project/roadmap.md#completing-the-language-design), +and +[completing the Carbon Explorer implementation of this design](/docs/project/roadmap.md#demo-implementation-of-core-features-with-working-examples). +Beyond that, we plan to prioritize C++ interoperability and a realistic +toolchain that implements the 0.1 language and can be used to evaluate Carbon in +more detail. + +You can see our [full roadmap](/docs/project/roadmap.md) for more details. ## Carbon and C++ -If you're already a C++ developer, Carbon should have a short learning curve. It -is built out of a consistent set of language constructs that should feel -familiar. C++ code like this: +If you're already a C++ developer, Carbon should have a gentle learning curve. +It is built out of a consistent set of language constructs that should feel +familiar and be easy to read and understand. + +C++ code like this: + +C++ is the dominant programming language for the performance critical software +our goals prioritize. The most direct way to deliver a modern and excellent +developer experience for those use cases and developers would be to improve C++. + +Improving C++ to deliver the kind of experience developers expect from a +programming language today is difficult in part because **C++ has decades of +technical debt** accumulated in the design of the language. It inherited the +legacy of C, including +[textual preprocessing and inclusion](https://clang.llvm.org/docs/Modules.html#problems-with-the-current-model). +At the time, this was essential to C++'s success by giving it instant and high +quality access to a large C ecosystem. However, over time this has resulted in +significant technical debt ranging from +[integer promotion rules](https://shafik.github.io/c++/2021/12/30/usual_arithmetic_confusions.html) +to complex syntax with +"[the most vexing parse](https://en.wikipedia.org/wiki/Most_vexing_parse)". + +**C++ has also prioritized backwards compatibility** including both syntax and +[ABI](https://en.wikipedia.org/wiki/Application_binary_interface). This is +heavily motivated by preserving its access to existing C/C++ ecosystems, and +forms one of the foundations of common Linux package management approaches. A +consequence is that rather than changing or replacing language designs to +simplify and improve the language, features have overwhelmingly been added over +time. This both creates technical debt due to complicated feature interaction, +and fails to benefit from on cleanup opportunities in the form of replacing or +removing legacy features. + +Carbon is exploring significant backwards incompatible changes. It doesn't +inherit the legacy of C or C++ directly, and instead is starting with solid +foundations, like a modern generics system, modular code organization, and +consistent, simple syntax. Then, it builds a simplified and improved language +around those foundational components that remains both interoperable with and +migratable from C++, while giving up transparent backwards compatibility. This +is fundamentally **a successor language approach**, rather than an attempt to +incrementally evolve C++ to achieve these improvements. + +Another challenge to improving C++ in these ways is the current evolution +process and direction. A key example of this is the committee's struggle to +converge on a clear set of high-level and long-term goals and priorities aligned +with [ours](https://wg21.link/p2137). When [pushed](https://wg21.link/p1863) to +address +[the technical debt caused by not breaking the ABI](https://wg21.link/p2028), +**C++'s process +[did not reach any definitive conclusion](https://cor3ntin.github.io/posts/abi/#abi-discussions-in-prague)**. +This both failed to meaningfully change C++'s direction and priorities towards +improvements rather than backwards compatibility, and demonstrates how the +process can fail to make directional decisions. + +Beyond C++'s evolution direction, the mechanics of the process also make +improving C++ difficult. **C++'s process is oriented around standardization +rather than design**: it uses a multiyear waterfall committee process. Access to +the committee and standard is restricted and expensive, attendance is necessary +to have a voice, and decisions are made by live votes of those present. The +committee structure is designed to ensure representation of nations and +companies, rather than building an inclusive and welcoming team and community of +experts and people actively contributing to the language. + +Carbon has a more accessible and efficient [evolution process](evolution.md) +built on open-source principles, processes, and tools. Throughout the project, +we explicitly and clearly lay out our [goals and priorities](goals.md) and how +those directly shape our decisions. We also have a clear +[governance structure](evolution.md#governance-structure) that can make +decisions rapidly when needed. The open-source model enables the Carbon project +to expand its scope beyond just the language. We will build a holistic +collection of tools that provide a rich developer experience, ranging from the +compiler and standard library to IDE tools and more. **We will even try to close +a huge gap in the C++ ecosystem with a built-in package manager.** + +Carbon is particularly focused on a specific set of [goals](goals.md). These +will not align with every user of C++, but have significant interest across a +wide range of users that are capable and motivated to evolve and modernize their +codebase. Given the difficulties posed by C++'s technical debt, sustained +priority of backwards compatibility, and evolution process, we wanted to explore +an alternative approach to achieve these goals -- through a +backwards-incompatible successor language, designed with robust support for +interoperability with and migration from C++. We hope other efforts to +incrementally improve C++ continue, and would love to share ideas where we can. diff --git a/docs/project/goals.md b/docs/project/goals.md index 1ff8a06fc023..14995ab2ffba 100644 --- a/docs/project/goals.md +++ b/docs/project/goals.md @@ -152,21 +152,19 @@ exact form this ends up taking. ## Language goals and priorities -We believe Carbon must support: +We are designing Carbon to support: -1. Performance-critical software. -2. Software and language evolution. -3. Code that is easy to read, understand, and write. -4. Practical safety and testing mechanisms. -5. Fast and scalable development. -6. Modern OS platforms, hardware architectures, and environments. -7. Interoperability with and migration from existing C++ code. +- Performance-critical software +- Software and language evolution +- Code that is easy to read, understand, and write +- Practical safety and testing mechanisms +- Fast and scalable development +- Modern OS platforms, hardware architectures, and environments +- Interoperability with and migration from existing C++ code -While many languages share subsets of these goals, what distinguishes Carbon is -their combination. For the Carbon project, they are prioritized in the above -order to help make clear what tradeoffs we intend to make. However, each and -every goal remains critically important: **Carbon _must_ have excellent C++ -interoperability and migration to be successful.** +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. ### Goals in detail diff --git a/proposals/p1270.md b/proposals/p1270.md new file mode 100644 index 000000000000..f3c36c773de6 --- /dev/null +++ b/proposals/p1270.md @@ -0,0 +1,130 @@ +# Update and expand `README` content and motivation for Carbon + + + +[Pull request](https://github.com/carbon-language/carbon-lang/pull/1270) + + + +## Table of contents + +- [Problem](#problem) +- [Background](#background) +- [Proposal](#proposal) +- [Details](#details) +- [Rationale](#rationale) +- [Alternatives considered](#alternatives-considered) + - [Avoid discussion of motivations](#avoid-discussion-of-motivations) + - [Avoid summarizing key language design areas](#avoid-summarizing-key-language-design-areas) + - [Avoid discussing the difficulty of directly and incrementally improving C++](#avoid-discussing-the-difficulty-of-directly-and-incrementally-improving-c) + + + +## Problem + +Feedback from folks outside of the immediate team working on Carbon surfaced +both some problems with the exact phrasing of our main README content, but more +importantly some major _gaps_ in our overall documentation. Specifically, we +failed to really explain our motivations for building Carbon and why this +approach might make sense. + +Given the significance of the new content and the importance of these specific +topics, this level of change seems important to go through the proposal process. + +## Background + +We've been trying to polish and improve the positioning and explanation of +Carbon to help understand whether it makes sense to shift the project towards +being a _public_ experiment instead of private one. + +## Proposal + +This PR includes a significant update to the [`README`](/README.md) content, as +well as adding [a new document](/docs/project/difficulties_improving_cpp.md) to +explain the difficulties with incrementally improving C++. + +It also tweaks the wording of our goals to try to further reduce confusion. + +## Details + +See the pull request for the detailed change. + +## Rationale + +- [Community and culture](/docs/project/goals.md#community-and-culture) + - We should document clearly our motivations to ensure that aspect of the + project remains transparent and clear. +- [Software and language evolution](/docs/project/goals.md#software-and-language-evolution) + - Understanding the _motivations_ of the Carbon project will be important + for future language evolution efforst. + +## Alternatives considered + +### Avoid discussion of motivations + +We could instead choose to avoid discussion of the project's motivations. This +has largely been the status-quo prior to this change. + +Advantages: + +- Less text. +- Fewer opportunities for a misunderstanding to develop. + +Disadvantages: + +- Fails to be transparent. We _do_ have motivations, and we can't + realistically pretend otherwise. +- Because we all _do_ have motivations, failing to write them down will + largely result in an inconsistent and lower-quality presentation of them in + informal discussions and forums. + +### Avoid summarizing key language design areas + +This proposal suggests some brief summaries around both +[generics](/README.md#generics) and [memory safety](/README.md#memory-safety). +We could instead skip these or only have a brief mention of these. + +Advantages: + +- Less text. +- May be inaccurate and will run the risk of drifting out of date. + - This was a larger concern previously when for example generics was + undergoing more active development. + +Disadvantages: + +- Fails to give people an easily consumed entry into some of the really + exciting aspects of the language design. +- Memory safety at least will likely be an immediate question for readers + where we can front-load a well considered answer. + +### Avoid discussing the difficulty of directly and incrementally improving C++ + +Previously we didn't go into details about the difficulties with incrementally +improving C++ itself that are an essential component of the motivation for +Carbon. We could stay with that approach. + +Advantages: + +- Less text. +- A very contentious subject that will have many divergent, well-reasoned, and + strongly held positions. +- Prior attempts to articulate this have ended up being easily misunderstood + or implying significantly more than was intended in a way that actually + reduced alignment between different readers rather than building alignment + and shared understanding. + +Disadvantages: + +- Despite the _difficulty_ of articulating this, it remains _important_. We + shouldn't avoid doing the work here merely because it is difficult. +- Omitting the discussion of these difficulties runs a risk of seeming + disingenuous -- the premise of the Carbon project makes it clear that there + is a significant motivation here. +- Overcoming the difficulty of articulating these difficulties well and in an + understandable form will significantly strengthen the Carbon project's + overall motivation and how it can engage with the broader industry.