并发编程是现代编程语言无法回避的核心议题。Rust与Go作为当前最受关注的两门系统级语言，各自提出了截然不同的并发原语：Go以轻量级goroutine闻名，Rust则通过async/await实现零成本异步。表面上看，它们都试图解决并发场景下的性能与开发复杂度，但支撑其背后的设计思想、运行时机制，以及开发者心智负担，有着深刻的差异。这种差异并非简单的技术路线之争，而是对‘调度权’归属问题的不同回答。
Go语言的goroutine由运行时全权托管，它的调度器将M个线程映射到N个goroutine上，并实现抢占式调度。每个goroutine初始栈仅为2KB，可动态伸缩，使得并发数量可以轻松达到百万级别。程序员只需要通过go关键字，即可启动一个新的执行单元，而通信则通过channel完成，遵循‘不要通过共享内存来通信，而要通过通信来共享内存’的哲学。这种设计将调度细节完全内聚在运行时，开发者的心智负担极低，但也导致在极端场景下，GC暂停和栈copy的开销成为隐忧。
Rust则走了一条完全不同的路。async/await在编译期将异步代码转换为状态机，不依赖运行时线程池，也没有GC。每个Future的大小在编译期已知，可以被精确地内联展开，从而获得极低的性能开销。但代价是，程序员必须手动选择合适的executor（如tokio、async-std），理解Send与Sync的约束，处理Pin和生命周期问题。Rust的并发模型是协作式的，只有显式await的地方才可能发生调度，因此对调度点的控制精确到行，这在高性能网络服务或嵌入式场景中是巨大的优势。
从本质上看，Go与Rust的并发模型分歧，其实是‘自动托管’与‘显式控制’这两种旧有理念在现代并发领域的再次交锋。Go将调度器视为运行时的一部分，认为程序员应专注于业务逻辑；Rust则将调度权下放给用户，认为编译器应该协助程序员掌控所有细节。两者都是正确的选择，只是它们服务的系统层级不同。Go适合快速构建IO密集的云服务，Rust适合精确控制资源的底层基础设施。盲目切换技术栈，往往会造成生产力的下降或性能的浪费。
未来，我认为这两种范式并非永久对立，而是会走向一种‘统一场’：运行时提供默认的可负担的自动调度，而语言层面提供显式的调度钩子，使得开发者可以在关键路径上获得零成本的确定性控制。例如，Go正在实验低延迟的异步预占机制，Rust则逐渐出现了更多类似tokio-unconsole的简化抽象。一旦隐藏的复杂度被工具链进一步封装，那么并发编程的极乐世界也许并非那么遥远。在此之前，理解‘税种’——是支付在认知负担上，还是支付在运行时开销上——是每位开发者做出技术选型时最需要清醒的地方。
