Carbon Language: no stable ABI by design, nightlies all tagged 0.0.0, and a Bazel toolchain

Every release is a nightly, and every nightly is version 0.0.0

The three most recent release tags are v0.0.0-0.nightly.2026.09.30, v0.0.0-0.nightly.2026.09.29 and v0.0.0-0.nightly.2026.09.28. One build per day, a date instead of a number, and a version component that never moves off zero.

That is not sloppiness in the tagging, it is the project telling you where it is. The README's own status section says Carbon Language is currently an experimental project and that it is not ready for use, repeated in the header link to the status section. There is no 0.1 release to pin, and the roadmap refers to a future 0.1 language as a minimum viable product for evaluation, which does not exist yet.

So the practical consequence is that there is no version constraint you can write in a manifest that means anything stable. You track trunk, whose default branch is not master but trunk, and you accept that any build can change. The last push to the repository was 2026-09-29, so the work is current, but current is not the same as usable.

The non-goals rule out a stable ABI and perfect compatibility

Most language projects list what they want. This one also lists what it will not do, and the non-goals are the most useful part of the README for an engineer. They are notably, a stable application binary interface for the entire language and library, and perfect backwards or forwards compatibility.

That single exclusion sets the ceiling on everything else. No ABI means compiled artefacts are not a stable interface between you and a future compiler version, so a plugin, an extension or a prebuilt library cannot be shipped and forgotten. No compatibility promise means source that compiles today may need changes tomorrow, and the migration work that C++ accumulated over decades is explicitly not something Carbon intends to reproduce.

The goals themselves are broad: 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 operating systems, hardware architectures and environments, and interoperability with and migration from existing C++ code. The README's own claim on those is that many languages share subsets of them, and what distinguishes Carbon is their combination. Reading the non-goals next to that list is the fastest way to see which of the goals are still aspirations.

Interop is the test of the design, and it is what contributors are told to build

The project frames itself as a successor language approach rather than an attempt to incrementally evolve C++, and it defines what that requires: performance matching C++, 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 scalable migration with some level of source-to-source translation for idiomatic C++ code.

Then the contributor guidance narrows that to one thing. People interested in contributing are told the project is currently focused on developing the toolchain until it can support Carbon to C++ interop, with a link into the roadmap. Beyond that, the plan is to keep developing the design and the toolchain until the 0.1 language can ship and support evaluating Carbon in more detail.

So the work that matters right now is plumbing, not syntax. A language that cannot call into C++ is a curiosity; a language that can is a migration path. The README also records that there was historically a prototype explorer interpreter implementing an older version of the language design, now no longer under development and archived, which is a useful reminder of how often the design underneath has changed.

The slot Carbon wants is the one TypeScript and Kotlin took

The README draws an explicit analogy. A few languages have followed a successor model for other ecosystems, and Carbon aims to fill the analogous role for C++. The list is short: JavaScript to TypeScript, Java to Kotlin, and C++ to Carbon.

That analogy is the honest way to evaluate the project, because it tells you what success and failure look like. TypeScript and Kotlin each succeeded by making adoption cheap at one point in a stack rather than by requiring a rewrite, and each kept enough compatibility with the original language that migration could be incremental. If Carbon follows that shape, the interesting question is not how the syntax compares to C++ but how expensive it is to move one library across the boundary.

The stated mechanism for that is source-to-source translation for idiomatic C++ code, plus the claim that builds stay fast and scalable by working with existing C++ build systems, and that low-level access to bits and addresses is preserved. Those three, performance, build integration and bit-level access, are the parts a C++ team will actually push on, and they are also the parts with the least detail behind them in the repository.

The README tells Rust, Go, Swift and Kotlin users to use those languages

There is a paragraph in the README that is more useful than any of the feature claims. It observes that existing modern languages already provide an excellent developer experience, naming Go, Swift, Kotlin, Rust and many more, and then states in bold that developers who can use one of these existing languages should.

The reasoning is specific rather than diplomatic. The designs of those languages present significant barriers to adoption and migration from C++, and those barriers range from changes in the idiomatic design of software to performance overhead. Carbon exists for the developer who has a large C++ investment and cannot leave, not for the developer choosing a language for a new service.

So the adoption test is narrow and you can apply it yourself. If your codebase is greenfield and your team is free to pick, the project's own recommendation is to pick one of those languages. If you have a decade of C++ with a performance requirement and a large migration budget, Carbon is the option that at least aims at your situation. Everything in between is where the interesting arguments are, and the project does not pretend otherwise.

Bazel builds the toolchain, and examples/re2_playground is the interop test

The repository tree is a compiler project, and the build system is Bazel. There is a .bazelversion file pinning it, a .bazelrc and a .bazelignore, a MODULE.bazel with a matching lock file for module resolution, a root BUILD file, and a bazel/ directory. Alongside that sit common/, core/, toolchain/, utils/, testing/ and integration_tests/, plus scripts/ and github_tools/.

The examples directory is the most instructive part. There is hello_world.carbon and sieve.carbon, an interop/ directory, an advent2024/ directory, a bazel/ subdirectory with a Python test runner called bazel_test_runner.py, and re2_playground/, which is the RE2 regular expression library. A playground for a real C++ library is a much better interop test than a toy example, because RE2 is the kind of dependency a C++ project actually has and the kind of API surface that exposes whether the boundary works.

Also visible are proposals/ for design work, a website/ directory matching the documentation site, .clang-format, .clang-tidy and .clangd for editor and lint integration, .gdbinit and .lldbinit for the two debuggers, CODEOWNERS, a code of conduct, CONTRIBUTING.md and SECURITY.md. The practical consequence is that building or hacking on this needs Bazel, a C++ toolchain and LLVM-adjacent tooling, not a text editor.

The Python tooling requires 3.12 and treats every type rule as an error

The pyproject.toml covers only the project's own Python, not the language implementation, and it is strict in a way that is worth noticing. requires-python is 3.12 or newer. Ruff is configured with a line length of 80, target version py312, and a rule set selecting E, F, W, I and ANN, with only ANN401 and ANN204 ignored, and separate per-file exemptions for test files, everything under proposals, the Bazel test runner and the lit configuration files.

Then the type checker configuration, which sets every rule to error and switches off only possibly-unresolved-reference, excludes the same set of files from analysis, and allows unresolved imports for exactly three things: rich, requests and bazel_tools.

Read together, that is a project holding its own tooling to a higher standard than most, and it also means a contributor needs a recent Python. The lit configuration files referenced in the exemptions indicate the tests are built around LLVM's lit harness, which is the other half of what you need installed before you can run the suite locally.

Editorial conclusion

Use Carbon Language if you are a C++ developer who wants to influence the design of a successor language, or you are evaluating whether the interop approach is worth following, and you can work from source. Do not plan a product on it: the non-goals explicitly exclude a stable application binary interface for the whole language and library, and perfect backwards or forwards compatibility, so there is nothing to build a dependency strategy around. Before you invest: read the non-goals before the goals, since they are the more useful filter; note that the version is 0.0.0 and the only releases are nightlies, so pinning means pinning a date; expect to build with Bazel from a repository whose default branch is trunk; and take the README's own advice seriously, because if you can use Go, Swift, Kotlin or Rust for your problem, it tells you to use that language instead.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes