c5ddb57dd7 Proposal for an explicit GitHub workflow. (#29)
* Proposal for an explicit GitHub workflow.

This suggests a GitHub workflow that uses pull requests, produces linear
history, and both incentivizes and encourages small, incremental changes
(both at the pull request and commit granularity). It tries to follow
general best practices around software engineering at scale and GitHub
workflows. It also tries to ensure the workflow is very well supported
by tooling and automation built into GitHub.

Of note, this proposal should match precisely the current enforced flow
on our GitHub repositories. But we need to actually decide we like this,
write up the rationale behind it, and document what we're doing.

I've added an abbreviated version of the proposal as a documentation
update to the contributing file. Happy to restructure or find a better
home for this. I've tried to focus on the parts that contributors
actually would need to care about as opposed to the things that are
simply and fully enforced mechanically.

My hope after this is to suggest more detailed code review guidelines.

* Addressing review comments.

Notably, I really was giving too much weight to multi-commit PRs which
shouldn't be the common or default. I've tried to restructure everything
to make it much more clear what is going on here.

* Minor tweaks

* Fix typo in CONTRIBUTING.md

Co-authored-by: josh11b <josh11b@users.noreply.github.com>

* Extract workflow description and remove redundancies.

* remove tracking issue template field

* Update proposals/p0029.md with reviewer suggsetion.

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>

* Continue to address review feedback.

* Apply suggestions from code review

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: austern <austern@google.com>

* Incorporate code review feedback and begin moving toward "trunk" based terminology

* Tweak the wording and make it a bit more consistent.

* Update docs/project/pull_request_workflow.md

Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>

* Address more review comments.

* Correct the rationale.

* Tweak wording based on discussion in review.

* Improve the rationale around the default branch to avoid overstating or
misstatig things.

* Apply suggestions from code review

Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>

* Clean up formatting and address a couple of comments on grammar from review.

* Update docs/project/pull_request_workflow.md

Co-authored-by: austern <austern@google.com>

* Add to proposal list.

Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: austern <austern@google.com>
2020-06-30 23:12:39 -07:00
2020-06-16 17:58:17 -07:00

Carbon language

The Carbon Language project is an experiment to explore a possible, distant future for the C++ programming language. It is designed around a specific set of goals, priorities, and use cases:

  1. Performance-critical software
  2. Both software and language evolution
  3. Code that is easy to read, understand, and write
  4. Practical safety guarantees and testing mechanisms
  5. Fast and scalable development
  6. Current hardware architectures, OS platforms, and environments as they evolve
  7. Interoperability with and migration from existing C++ code

The first six of these represent a set of priorities for C++ shared by a significant subset of the C++ community, industry, and ecosystem. However, C++ is increasingly constrained by a diverse set of concerns and priorities (including some that are irrelevant to or in opposition to these goals, such as ABI stability), and carries a significant historical legacy that makes it challenging to evolve effectively. The result is that these users struggle to meet our goals using C++ today, and that is unlikely to change in the near future. Carbon is an attempt to explore what it would look like to rapidly and systematically re-engineer C++ into a near optimal future state along the top six priorities, which nonetheless is still reachable through interoperability, tooling, automation, and incremental large-scale migration efforts.

For more information, see our goals document.

What about other languages?

Other programming languages don't currently address these needs effectively. They present interoperability, migration, and performance challenges that make it expensive and potentially impossible to migrate a large C++ code base. An approach which requires rewriting an entire binary at once would be infeasible. A large-scale migration must be incremental, meaning that interoperability and tool-assisted code rewrites are critical.

There are projects for several languages to reduce obstacles affecting migration from C++. Some contributors to Carbon are also contributing to those efforts in parallel in order to understand all of the options in this space. TODO: write up a detailed analysis of these languages specifically through the lens of the above goals.

One especially interesting aspect not addressed by the active and widely used languages that might serve this purpose is that they have not been designed specifically to enable migration from and interoperability with today's C++. They don't build on top of C++'s existing ecosystem. There are only a few significant examples of programming languages that center around incremental migration of large existing codebases. They are specifically designed to not require complete rewrites, new programming models, or building an entire new stack/ecosystem. However, there is no comparable option for C++ today:

  • JavaScript → TypeScript
  • Java → Kotlin
  • C++ → ???

Carbon explores what it would look like to fill this gap and align it with the above priorities.

Project status

The project is just getting started. Everything is at a very early stage. If you are hoping to see lots of concrete ideas and plans, you'll probably want to check back in 6 months to a year. At this stage, we're just beginning to lay the foundations.

It is important to understand that this is a science experiment, not a production effort. There are several initial questions that we want to explore and answer with this experiment:

  • Can we deliver a design and implementation that is familiar and compelling to C++ programmers and supports our goals?
  • How seamless and effective can we make interoperability?
  • How easy and scalable can we make migration?
  • Will a significant segment of the ecosystem and industry adopt Carbon given these tradeoffs?

We are committed to learning the answers to these questions, but that may well not result in a production language. There is a very real chance that this project will never leave the experimental phase. Anyone considering contributing or using Carbon should be extremely mindful of that fact: core contributors may abandon the experiment.

While we may sometimes refer to Carbon as a language, it is crucial to understand that the goals of this science experiment are not about new languages, but about how to move today's C++ forward effectively. For example, a near optimal outcome would be to convince the C++ community to adopt this as its official path forward.

What will make Carbon a compelling future path for C++?

We hope that eventually Carbon will provide significant advantages compared to today's C++. Areas where we think we can most dramatically improve C++ for both software systems and developers are:

  • A cohesive and principled language design, even when supporting advanced features.
  • Making common coding patterns safe by default whenever practical, with affordable security mitigations available for any unsafety.
    • We will provide static checks for as many safety issues as we can by default.
    • We will provide a spectrum of build modes with different trade-offs between dynamic safety and performance. For example:
      • The default build mode will include as many dynamic safety checks as we can while keeping the software's performance reasonable for normal development, testing, and debugging.
      • Release builds will favor performance, with opt-in dynamic safety checks and security mitigations for applications with higher security requirements.
    • Over time, we also expect to both track and drive research into increasing the degree of safety available without compromising our other goals.
  • Keeping our core language implementation simple, fast, and easily extended in ways that will make all of our language tools better.
  • Providing an effective, open, and inclusive language evolution process aligned with our goals and priorities.

Carbon will also aim to allow a single layer of a legacy C++ library stack to be migrated to Carbon, without migrating the code above or below. This will make it easier for developers to start using Carbon. Key features underpin Carbon's compatibility and interoperability with C++:

  • The memory, execution, and threading model will be compatible with C++.
  • Access to existing C++ types, interfaces, and even templates will be provided as part of the core language.
  • Carbon will be able to export types, interfaces, and templates for consumption by C++.

However, Carbon's approach still requires a nearly complete re-engineering of the language as well as large-scale migration for users. This is extremely expensive, and so the bar for Carbon to be a compelling direction for C++ is very high.

Repository structure overview

Carbon's main repositories are:

  • carbon-lang - Carbon language specification and documentation.
  • carbon-toolchain - Carbon language toolchain and reference implementation.
  • carbon-proposals - An archive of reviewed Carbon language proposals.
S
Description
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
Readme Apache-2.0
2.7 GiB
Languages
C++ 89.4%
Starlark 4.5%
Python 3.6%
Carbon 1.6%
JavaScript 0.4%
Other 0.2%