mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-25 20:40:15 +01:00
206 lines
9.6 KiB
Markdown
206 lines
9.6 KiB
Markdown
# Roadmap
|
|
|
|
<!--
|
|
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
|
Exceptions. See /LICENSE for license information.
|
|
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
-->
|
|
|
|
<!-- toc -->
|
|
|
|
## Table of contents
|
|
|
|
- [Objective for 2021: speed up Carbon development](#objective-for-2021-speed-up-carbon-development)
|
|
- [Key results in 2021](#key-results-in-2021)
|
|
- [Broaden core team representation so no organization is >50%](#broaden-core-team-representation-so-no-organization-is-50)
|
|
- [Example ports of C++ libraries to Carbon (100% of woff2, 99% of RE2)](#example-ports-of-c-libraries-to-carbon-100-of-woff2-99-of-re2)
|
|
- [Language design covers the syntax and semantics of the example port code.](#language-design-covers-the-syntax-and-semantics-of-the-example-port-code)
|
|
- [Demo implementation of core features with working examples](#demo-implementation-of-core-features-with-working-examples)
|
|
- [Executable semantic specification for core features with test cases](#executable-semantic-specification-for-core-features-with-test-cases)
|
|
- [Beyond 2021](#beyond-2021)
|
|
- [Potential 2022 goals: finish 0.1 language, make it public](#potential-2022-goals-finish-01-language-make-it-public)
|
|
- [Potential 2023 goals: finish 0.2 language, stop experimenting](#potential-2023-goals-finish-02-language-stop-experimenting)
|
|
- [Potential 2024-2025 goals: _ship_ 1.0 language & organization](#potential-2024-2025-goals-_ship_-10-language--organization)
|
|
|
|
<!-- tocstop -->
|
|
|
|
## Objective for 2021: speed up Carbon development
|
|
|
|
The main objective of the Carbon project in 2021 is to speed up the development
|
|
of the project, even while it remains both an experiment and private. This will
|
|
require improving at least two dimensions:
|
|
|
|
- Increase the investment by existing individuals and organizations.
|
|
- Increase the breadth of different individuals and organizations investing in
|
|
Carbon.
|
|
|
|
We expect to make progress on this objective in 2021 primarily by making
|
|
Carbon's design more concrete and with a more specific and easily understood
|
|
value proposition. As a result, our key results are primarily around specific
|
|
artifacts that we think will help support the scaling up of Carbon development
|
|
efforts.
|
|
|
|
We also need to identify key missing participants and onboard them
|
|
throughout 2021.
|
|
|
|
## Key results in 2021
|
|
|
|
There are several milestones that we believe are on the critical path to
|
|
successfully achieving our main goal for the year, and point to concrete areas
|
|
of focus for the project.
|
|
|
|
### Broaden core team representation so no organization is >50%
|
|
|
|
Our goal is that no single organization makes up >50% of the core team to ensure
|
|
that we are including as broad and representative a set of perspectives in the
|
|
evolution of Carbon as possible.
|
|
|
|
### Example ports of C++ libraries to Carbon (100% of [woff2](https://github.com/google/woff2), 99% of [RE2](https://github.com/google/re2))
|
|
|
|
The first part of this result is that all of the woff2 library is ported to
|
|
Carbon in a way that exports the same C++ API. There should be no gaps in this
|
|
port given that woff2 has a very simple C++ API and uses few C++ language
|
|
features.
|
|
|
|
RE2 is a larger library using significantly more language features. For that
|
|
part of the result, fewer than 1% of its C++ lines of code should be missing a
|
|
semantically meaningful port into Carbon code.
|
|
|
|
An important nuance of this goal is that it doesn't include building a complete
|
|
Carbon standard library beyond the most basic necessary types. The intent is to
|
|
exercise and show the interoperability layers of Carbon by re-using the C++
|
|
standard library in many cases and exporting a compatible C++ API to both woff2
|
|
and RE2's current API.
|
|
|
|
While this key result isn't directly tied to the main objective, we believe it
|
|
represents a critical milestone for being able to achieve this objective. It
|
|
both measures our progress solidifying Carbon's design and demonstrating the
|
|
value proposition of Carbon.
|
|
|
|
Note that both woff2 and RE2 libraries are chosen somewhat arbitrarily and could
|
|
easily be replaced with a different, more effective libraries to achieve the
|
|
fundamental result of demonstrating a compelling body of cohesive design and the
|
|
overarching value proposition.
|
|
|
|
#### Language design covers the syntax and semantics of the example port code.
|
|
|
|
We should have a clear understanding of the syntax and semantics used by these
|
|
example ports. While this should include accepted proposals, it doesn't
|
|
necessarily require either formal specification or implementation.
|
|
|
|
### Demo implementation of core features with working examples
|
|
|
|
A core set of Carbon features should be implemented sufficiently to build
|
|
working examples of those features and run them successfully. These features
|
|
could include:
|
|
|
|
- User-defined types, functions, namespaces, packages, and importing.
|
|
- Basic generic functions and types using interfaces.
|
|
- Initial/simple implementation of safety checking including at least bounds
|
|
checking, simple lifetime checking, and simple initialization checking.
|
|
- Sum types sufficient for optional-types to model nullable pointers.
|
|
- Pattern matching sufficient for basic function overloading on types and
|
|
arity, as well as unwrapping of optional types for guard statements.
|
|
|
|
Stretch goals if we can hit the above:
|
|
|
|
- Instantiating a basic C++ template through interop layer for use within
|
|
Carbon.
|
|
|
|
The demo implementation should also provide demos outside of specific language
|
|
features including:
|
|
|
|
- Basic benchmarking of the different phases of compilation (lexing, parsing,
|
|
etc).
|
|
- A basic REPL command line.
|
|
|
|
Stretch goals if we can hit the above:
|
|
|
|
- Automatic code formatter on top of the implementation infrastructure.
|
|
- A [compiler explorer](https://compiler-explorer.com/) fork with REPL
|
|
integrated.
|
|
|
|
Benchmarking at this stage isn't expected to include extensive optimization.
|
|
Instead, it should focus on letting us track large/high-level impact on
|
|
different phases as they are developed or features are added. They may also help
|
|
illustrate initial high-level performance characteristics of the implementation,
|
|
but the long term focus should be on end-to-end user metrics.
|
|
|
|
Automatic code formatting could be achieved many ways, but it seems useful to
|
|
ensure the language and implementation both support use cases like formatting.
|
|
|
|
### Executable semantic specification for core features with test cases
|
|
|
|
This should include both a human readable rendering of the formal semantics as
|
|
well as an execution environment to run test cases through those semantics. The
|
|
core features which should be covered by these semantics are:
|
|
|
|
- User-defined types, functions, namespaces, packages, and importing.
|
|
- Basic generic functions and types using interfaces.
|
|
- Sum types sufficient for optional-types to model nullable pointers.
|
|
|
|
This is intentionally a subset of the features covered by the demo
|
|
implementation. The intent is to reflect that _completing_ coverage of the
|
|
features in the specification is a slightly lower priority, and instead we
|
|
should rapidly spike out as complete of a demo as possible and come back to the
|
|
semantics if possible.
|
|
|
|
## Beyond 2021
|
|
|
|
Longer term goals are hard to pin down and always subject to change, but we want
|
|
to give an idea of what kinds of things are expected at a high level further out
|
|
in order to illustrate how the goals and priorities we have in 2021 feed into
|
|
subsequent years.
|
|
|
|
### Potential 2022 goals: finish 0.1 language, make it public
|
|
|
|
We expect that at some point in 2022 we will need to shift the experiment to be
|
|
public. This will allow us to significantly expand both those directly involved
|
|
and contributing to Carbon but also those able to evaluate and give us feedback.
|
|
|
|
We don't expect Carbon to shift away from an experiment until after it becomes
|
|
public and after we have been able to collect and incorporate a reasonable
|
|
amount of feedback from the broader industry and community.
|
|
|
|
We'll also need to start broadening our scope:
|
|
|
|
- Expand the standard library to at least cover everything needed for self
|
|
hosting.
|
|
- Develop initial C++ to Carbon migration tooling.
|
|
|
|
### Potential 2023 goals: finish 0.2 language, stop experimenting
|
|
|
|
Once Carbon is moving quickly and getting public feedback, we should be able to
|
|
conclude the experiment. We should know if this is the right direction for
|
|
moving C++ forward for a large enough portion of the industry and community, and
|
|
whether the value proposition of this direction outweighs the cost.
|
|
|
|
However, there will still be a _lot_ of work to make Carbon into a production
|
|
quality language, even if the experiment concludes successfully.
|
|
|
|
Some concrete goals that might show up in this time frame:
|
|
|
|
- Self-hosting toolchain, including sufficient Carbon standard library
|
|
support.
|
|
- Expand design of standard library to include, at least directionally,
|
|
critical and complex areas. For example: concurrency/parallelism and
|
|
networking/IO.
|
|
- Migration tooling sufficient to use with real-world libraries and systems.
|
|
This might be used to help with self-hosting Carbon, as well as by initial
|
|
early adopters evaluating Carbon.
|
|
|
|
### Potential 2024-2025 goals: _ship_ 1.0 language & organization
|
|
|
|
A major milestone will be the first version of a production language. We should
|
|
also have finished transferring all governance of Carbon to an independent open
|
|
source organization at that point. However, we won't know what a more realistic
|
|
or clear schedule for these milestones will be until we get closer.
|
|
|
|
Another important aspect of our goals in this time frame is expanding them to
|
|
encompass the broader ecosystem of the language:
|
|
|
|
- End-to-end developer tooling and experience.
|
|
- Teaching and training material.
|
|
- Package management.
|
|
- Etc.
|