Carbon is still for evaluation, not production
Carbon's README calls the language experimental and says it is not ready for use. The project aims to give C++ developers a more regular syntax, checked generics, modular code organization, and a path toward stronger safety. Its toolchain already compiles and links Carbon programs, and a browser build is available through Compiler Explorer. Those are useful ways to study the language. They are not a production support promise.
The project's own milestone document draws the line clearly. Version 0.1 is a minimum product for serious evaluation, 0.2 is meant to become feature complete enough to finish that evaluation, and 1.0 is the first milestone described as usable in production. Carbon has not published a stable GitHub release at any of those levels. The available artifacts are dated 0.0.0 nightly prereleases.
The proposed two-step migration keeps existing C++ in the picture
Carbon proposes a two-step route: move C++ into an interoperable Carbon dialect, then refactor that code toward safer patterns and APIs. The attraction is incremental scope. A large application would not have to translate every dependency before one library could change languages. Carbon also avoids promising a permanent ABI or perfect backward compatibility, choices intended to leave room for language and tooling upgrades.
That pitch remains partly a design target. The README says the toolchain is being developed to compile Carbon and eventually compile C++ code as well. Source translation for idiomatic C++ is described as planned. Memory safety is framed as an incremental destination, starting with better initialization handling, bounds checking support, less undefined behavior, and visible unsafe syntax. A buyer should not read those goals as features ready today.
What happened when we ran it
Our sandbox installed commit f819faf in 16 seconds, adding 35 packages and occupying 37 MB. The available build step succeeded in 4 seconds. The environment was a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and a Python 3.12 uv image. Pip-audit found 0 known vulnerabilities in the installed Python dependency set.
No tests script or target was available to the lab, so the test stage was skipped. That means our run produced no passing or failing test count for Carbon. The checkout itself held 5,501 files, roughly 186,338 lines of source, and 40 MB before installation. We found 14 CI workflow files, no Dockerfile, and no tests directory. Those repository signals do not substitute for a test result.
Nightly 0.0.0 builds are easier than compiling the toolchain
The README's shortest local route is a nightly tarball for a recent Ubuntu, Debian, or WSL system. Its example downloads a date-stamped 0.0.0-0.nightly.YYYY.MM.DD archive, compiles a small file, installs libgcc-11-dev, and links an executable. GitHub published nightly 2026.09.11 on September 11, which confirms a current artifact stream while also advertising its prerelease status in the version number.
Source contributors face a wider setup. Carbon documents Clang 19 or newer, LLD, libc++, Bazelisk, uv, and prek on Debian or Ubuntu. macOS uses Homebrew, and Windows developers are directed to WSL. Our 16-second Python install did not exercise that full native compiler path. Someone planning to work on parsing, semantic IR, LLVM lowering, or C++ interop should budget for the documented toolchain rather than the smaller lab dependency result.
Current nightlies still crash on specific C++ interop cases
Issue 7731 reports a compiler crash in nightly 0.0.0-0.nightly.2026.09.06 when a two-file example calls Cpp.malloc; importing the same C++ header from the main Carbon file is given as a workaround. Issue 7721 shows another crash while lowering a Carbon class that overrides a virtual function from a C++ base. An open pull request on September 11 was working on the latter failure.
These reports match the stated development stage. Carbon's roadmap focuses first on accessing most non-template C++ APIs from Carbon, with the reverse direction described as a stretch goal in its 2025 objectives. Template interop, migration tooling, and the safety design cover harder ground beyond a demo. A company evaluating the language should use its own headers and inheritance patterns because a toy program cannot reveal which interop boundaries its codebase will hit.
September 11 activity shows speed, while 259 open items show unfinished work
GitHub recorded Carbon's last push on September 11, 2026, and the latest open pull requests were moving the toolchain, diagnostics, parser, and semantic IR that same day. The repository had 33,887 stars and 259 open issues and pull requests combined. Fourteen CI workflow files and daily nightly releases reinforce the picture of an active engineering project. The combined open count is not a defect count.
The planning documents are less current than the code. The roadmap still labels its main section as 2025 objectives and describes the end of 2026 as the soonest 0.1 might ship. September 2026 activity is easy to verify, but the document does not say that 0.1 has shipped. Until the milestones receive a dated status update, use the README's plainer statement: the language is experimental and many parts do not work.
A 4-second check supports research, not a production language decision
Our build step passed in 4 seconds and the dependency audit found 0 known vulnerabilities, which clears a narrow repository check. The missing test target and explicit experimental status keep the verdict conservative. Carbon makes the most sense for compiler contributors and C++ organizations funding an evaluation of future migration. If the next project needs a supported language, stable compatibility expectations, or memory safety in deployed code, Rust, Swift, or the existing C++ toolchain is the practical choice.