Carbon 编程语言再初尝试：时隔多年，它到底变成了什么样？

原创已于 2025-07-19 14:12:25 修改 · 1.1k 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#carbon #后端 #c++

于 2025-07-19 14:02:37 首次发布

Carbon 编程语言再初尝试：时隔一年，它到底变成了什么样？

Google 在 CppNorth 大会上把 Carbon 的代码仓库“哐”地一声公开之后，我就一直很期待这门语言。

之后，我抱着尝鲜的心理去试用了一下。当时最大的感受是：

“语法像 Rust，目标像 Go，生态还约等于 0”。一年过去，GitHub Star 从 2k 涨到了 14k，官方也发布了 0.2/0.3 两个 milestone。于是我决定“再尝一口”——看看它到底进化到了哪一步，以及值不值得继续投入时间。

TL;DR

编译器：从玩具级到了“能跑小工具”级，但依旧没有包管理器

语法：去掉了大量“看起来像 Rust”的符号，新增 `choice`/`match`/`class` 等关键字

工具链：`carbon` 命令现在可以 `run`、`test`、`fmt`，但仍需 LLVM 17+ 手动编译

缺点：Linux-only、调试信息简陋、标准库小得可怜

结论：还处在“给语言设计者自己用”的阶段，想写业务代码至少再等一年

环境搭建：还是逃不掉自己编译LLVM 的地狱

官方 README 依旧写着 “Use our Docker image if you don’t want to build LLVM”。

但作为一个偏执的本机党，我还是在 Ubuntu 22.04 上硬刚了一次。步骤和一年前几乎一模一样：

sudo apt install llvm-17 llvm-17-dev clang-17 lld-17
git clone https://github.com/carbon-language/carbon-lang
cd carbon-lang
bazel build //explorer:carbon

好消息：编译时间从 40 min 降到了 18 min（i7-12700 + 32 GB）。

坏消息：如果系统里混了 LLVM 14/15/16，Bazel 依旧会抽风——记得 `export LLVM_CONFIG_PATH=/usr/bin/llvm-config-17`。

标准库命名习惯发生了变化

去年：

package Sample api;
fn Main() -> i32 {
Print("Hello, world!");
return 0;
}

今年（0.3 语法）：

package Hello api;
fn Main() -> i32 {
Console.WriteLine("Hello, world!");
return 0;
}

主要变化：

`Print` 变成了 `Console.WriteLine`，更像 .NET
分号可选（是的，Carbon 终于也玩起了“可选分号”）
`Main` 不再强制要求 `-> i32`，可以写 `fn Main()`，默认返回 0

类型系统：choice 与 match 的化学反应

去年社区吐槽最多的一点是：“Carbon 的 `match` 怎么长得像 C++17 的 `if constexpr`？”

0.3 版本直接把 `enum` 换成了 `choice`（sum type），并给 `match` 加了 exhaustiveness 检查：

choice OptionalInt {
Some(i32),
None,
}

fn AddOne(o: OptionalInt) -> OptionalInt {
match (o) {
case .Some(n) => return .Some(n + 1);
case .None => return .None;
}
}

编译器会提示：

> error: match is not exhaustive, missing case `_`

这一点比 Rust 还严格（Rust 允许用 `_ => unreachable!()` 糊弄过去）。

泛型：concept 的半成品

Carbon 的泛型目前支持 `constraint`（类似 C++ concept）：

constraint Addable {
fn Add[addr me: Self](rhs: Self) -> Self;
}

class MyInt {
var value: i32;
fn Add[addr me: Self](rhs: Self) -> Self {
return {.value = me->value + rhs.value};
}
}

但真正写起来会发现：
- 无法给已有类型（如 `i32`）外挂实现
- 没有 `where` 子句，只能用 SFINAE 风格约束
- 编译错误信息依旧是 LLVM IR 级别的“乱码”

一句话：能跑，但不够甜。

标准库的从 0 到 0.1

一年前的标准库只有 `Print` 和一个裸指针包装器。

现在多了：

- `String`（本质是 LLVM 的 `std::string` 薄包装）
- `Vector`（可增长数组）
- `HashMap`（基于 LLVM 的 `DenseMap`）
- `Random`（xoshiro256++）

但没有文件 I/O、网络、线程、时间。

所以写个 “wc -l” 都得自己调 C FFI：

fn OpenFile(path: String) -> i32 {
return __llvm_intrinsic_fopen(path.Pointer(), "r".Pointer());
}

调试：GDB 能看到符号，但看不到名字

编译器支持 `-g` 生成 DWARF，但变量名被 mangling 成 `_ZN6Main3FooE` 这种 LLVM IR 风格。

GDB 里打 `bt` 能看到行号，可 `p my_var` 会提示 `<incomplete type>`。

官方答复：

> 我们还没写 name demangler，先凑合用 `llvm-dwarfdump` 人肉查。

单元测试：终于不用手写 main 了

package MyMath api;
fn Square(x: i32) -> i32 { return x * x; }

#[Test]
fn TestSquare() {
Assert(Square(3) == 9);
}

运行：
bazel test //explorer:test --test_arg=MyMath

结果：

[----------] 1 tests from MyMath
[ RUN ] TestSquare
[ OK ] TestSquare (18 ms)
[----------] 1 tests from MyMath (22 ms total)

终于有点现代语言的味道了。

我的 100 行练习：Brainfuck 解释器

为了验证“能不能写点真东西”，我花了一个下午把去年的 Brainfuck 解释器重写了。

感受如下：

- 语法噪音比 C++ 少 30%，没有 header/forward declaration
- borrow checker 依旧缺席，指针随便 aliasing，内存安全全靠自觉
- 编译速度比 Clang 快 2 倍，但运行速度比 -O2 的 C++ 慢 20%（因为 LLVM IR 没开优化）