Cantrill Bests Hand-Optimized C in Rust, Urges Overhaul of Firmware

Cantrill用Rust击败手工优化C代码，呼吁彻底革新固件 Rust将具有缓存意识的数据结构与编译期所有权相结合，其性能超越了手工优化的C语言，为系统工程师提供了一种在不牺牲执行速度的前提下消除系统性固件安全缺陷的途径。 Bryan Cantrill围绕平台价值观和技术权衡来界定编程语言的选择，阐明了C语言对性能的极致追求如何迫使几代系统工程师不得不手动承担安全与稳定性的重任。回顾由Spectre和Meltdown引发的行业危机，他认为基础底层设施迫切需要兼具裸机级的极致性能与坚不可摧的软件完整性。Cantrill详细介绍了如何用地道的Rust重写一个对性能至关重要且经手工优化的C语言组件，得益于Rust对缓存友好的集合基元以及所有权模型，其最终表现超越了原有的C实现。他着重强调了代数数据类型、卫生宏以及显式unsafe边界等语言特性，将Rust定位为一项革新用户级基础设施的变革性技术，有助于整个行业推进脆弱硬件固件的现代化改造。 正如C、OpenBSD、Awk和K截然不同的设计理念所展现的那样，编程语言的选择从根本上取决于团队和问题价值观与社区权衡的相互契合。 (2:05) 2018年爆发的Meltdown和Spectre硬件漏洞证明，如果底层的微处理器为了纯粹的性能而牺牲安全性，那么系统软件也无法维护安全。 (14:17) 用Rust重写性能关键型C应用程序的速度超过了手工优化的C代码，这是因为Rust能够切实采用具有缓存效率的B树，而非容易造成内存碎片的AVL树。 (27:10) Bryan Cantrill认为，计算领域正处于与存在缺陷的遗留汇编及C固件的存亡冲突之中，他将内存安全的Rust定位为改造底层设施的核心武器。 (33:39)

Bryan Cantrill argues that software platforms are defined by the trade-offs they make among competing values, and that systems software has long suffered from C’s singular focus on performance at the expense of safety. He contends that Rust resolves this historical dilemma by combining compile-time memory safety with bare-metal speed, providing a viable path to modernize critical infrastructure without sacrificing performance. Software Values and Cultural Alignment (2:05) Cantrill defines software values as the positive traits chosen when trade-offs become unavoidable. Because no single platform can maximize every desirable attribute—such as performance, robustness, expressiveness, and simplicity—a platform's identity is determined by which quality it prioritizes when two virtues conflict. These foundational trade-offs act as a cultural magnet, attracting engineers who defend those priorities across generations. Contrasting language ecosystems illustrate this divergence. The array language K sacrifices readability and maintainability for extreme brevity and raw execution speed. In contrast, OpenBSD treats security as its sole governing value, intentionally disabling hyper-threading and shedding half of its virtual execution contexts because it deemed them vulnerable to side-channel attacks. Cantrill stresses that selecting a programming language inevitably means selecting an open-source community, warning that a cultural misalignment between user values and platform values will eventually cause the software to fail the user's operational needs. The Fragility of C-Centric Systems Infrastructure (19:02) Systems software foundations must satisfy demanding requirements: compatibility, debuggability, resilience, robustness, security, and performance. Cantrill observes that C and C++ share only one core value with this required set: performance. Consequently, decades of operating system stability were achieved not because of the C language, but despite it—sustained entirely through programmer discipline, code reviews, and testing without compiler-level memory safety nets. When a lower substrate compromises security to chase speed, higher software layers lose their footing. Cantrill points to the 2018 Spectre and Meltdown speculative execution flaws, where the hardware industry spent decades sacrificing security for microprocessor performance, forcing systems engineers to spend a year recovering basic baseline integrity. Dynamic environments like Node.js failed to solve systems challenges because they prioritized approachability and community growth, which Cantrill contrasts with the systems imperative to reject abstractions that introduce obscure, unpredictable edge cases. Safe Composition and Cache-Conscious Performance (25:05) Cantrill notes that Rust overcomes C's primary deficiency—composition across library boundaries where dynamic memory ownership is ambiguous—by using a strict compile-time model of ownership and borrowing. This contract provides the memory ergonomics of a garbage-collected language alongside zero-cost abstractions, avoiding runtime garbage collector overhead while preventing memory dereference and leak bugs. To test whether safety penalties would hinder performance, Cantrill rewrote an existing, hand-optimized C tool in Rust. The idiomatic Rust implementation ran faster than the original C version. Profiling revealed the C code had bottlenecked on an AVL tree, whereas Rust used its standard B-tree library. While B-trees were traditionally associated with spinning disks, modern memory hierarchies make DRAM behave like a slow disk relative to CPU caches. Cantrill points out that Rust unlocked this cache-friendly architecture because developers can safely import sophisticated standard data structures that are notoriously difficult to implement and maintain safely in C. Shifting Cognitive Load and Modernizing Firmware (31:37) Rust intentionally shifts the cognitive burden of software reliability from production operators triaging crashes to developers working at their desks. While wrestling with the borrow checker creates development friction, Cantrill argues it flags genuine latent defects. Rather than demanding wholesale rewrites of legacy kernels, Rust facilitates iterative adoption through its Foreign Function Interface (FFI) and algebraic data types, while using the explicit `unsafe` keyword to isolate low-level pointer manipulation to auditable boundaries. Beyond user-space tools, Cantrill identifies platform firmware as the most critical target for Rust adoption. Most modern firmware remains written in legacy C and assembly, creating fragile, insecure foundations beneath the operating system. Cantrill characterizes this challenge as an urgent priority for computing infrastructure, asserting that replacing brittle firmware with memory-safe Rust represents one of the language's highest-value opportunities. Cantrill emphasizes that while Rust is not a universal solution for every programming domain, it uniquely aligns with the core requirements of systems infrastructure. The unresolved challenge lies in overcoming the compiler's steep initial learning curve and systematically displacing entrenched, insecure C and assembly implementations in low-level platform firmware.

Bryan Cantrill 在演讲中指出，选择编程语言本质上是选择其背后的核心价值观与开源社区；长期以来系统软件被迫以牺牲安全性为代价来换取性能，而 Rust 通过所有权模型与严格的编译期保证，首次让底层系统开发在保持顶尖性能的同时兼顾稳健性与内存安全。 技术选型的本质是核心价值观与社区的权衡 (2:05) Cantrill 提出，评估技术平台不能脱离其核心价值观。每种语言或平台在面临性能、稳健性、表达力、可调试性等互相冲突的积极特质时，都必须做出取舍，而这种取舍定义了平台的底色并吸引志同道合的工程师共同维护。例如，Arthur Whitney 设计的 K 语言将极致表达力与性能置于首位，不惜彻底牺牲可读性与维护性；OpenBSD 则将安全性视作唯一信条，甚至愿意直接禁用超线程、舍弃半数虚拟核心以防范侧信道攻击；Awk 追求极简与易用，其约 130 页的经典文档两小时即可通读掌握；Scala 则依托与 Java 的互操作性，在 JVM 生态上追求高表达力与健壮性。Cantrill 警告称，如果所选社区的价值观与自身工程需求冲突，后续协作与系统演进必然产生严重摩擦。 C 与 C++ 的历史局限与系统底层的安全危机 (5:49) 回顾系统软件发展史，C 语言最初作为可移植汇编诞生，唯一不可妥协的核心目标就是极致性能与底层互操作性，诸如结构体等特性也是后期为了编写 UNIX 才被迫引入。C++ 虽追求表达力，却走向极度复杂且跨语言互操作性极差。长期以来，操作系统的健壮性并非来自语言本身的保障，而是靠资深工程师审慎的代码审查、手动内存管理和专用工具苦苦维系。随着 2018 年初曝光的 Spectre 和 Meltdown 漏洞，硬件厂商数十年来牺牲安全盲目追求性能的恶果彻底爆发，导致底层基准崩塌，系统工程师耗费整年时间也仅能勉强修复原有安全假设。Cantrill 引用 Roger Faulkner 的名言指出“性能是万恶之源”，但在底层基建中性能又是经济成本的刚性要求，无法被简单舍弃；而 Node.js 等强调“易学易用”的高级语言，其宽容边缘条件的取向又根本无法满足系统层对绝对确定性的严苛要求。 Rust 所有权机制对经典 C 程序的性能超越 (25:05) 在历经对传统工具链的失望后，Cantrill 关注到 Rust 的编译期所有权与借用机制。与垃圾回收或纯手动跟踪指针不同，Rust 让编译器在编译阶段自动确定内存分配与释放时机，不仅消除手动跟踪负担，更解决了 C 语言在组件跨边界调用时最易引发的内存泄漏与破坏难题。为了验证其实用性，Cantrill 将一段高度手动优化的 C 语言核心代码重写为 Rust。在克服对借用检查器的初期挣扎后，基准测试显示 Rust 版本的运行速度显著超越了原始 C 代码，Clang 编译也未能改变这一物理差距。原因在于，现代内存层级中 DRAM 访问相对 CPU 缓存而言已如同慢速磁盘，Rust 标准库开箱即用的 B 树相比传统 C 程序中手写的 AVL 树具有极高的缓存友好性，外加所有权语义赋予编译器的激进优化能力，彻底打破了“安全语言必然牺牲性能”的迷思。 认知负荷前置与系统固件的现代代际变革 (29:39) 在语言工程实践上，Rust 引入代数数据类型使错误处理极为紧凑，配合卫生宏与标准 C FFI，让底层交互更加规整。Cantrill 认为 `unsafe` 关键字并非缺陷，而是可审计的显式隔离舱，它将破坏编译期不变量的代码限制在极小范围内，防止未定义行为污染整座系统架构。Rust 的核心折中在于将认知负荷大幅前置：它把运维人员在生产环境中排查崩溃的巨大痛苦，转移为开发者在编码阶段与编译器借用检查器的拉锯。更为关键的是，Rust 不谋求推倒重写一切，而是支持通过互操作性逐步改造现有系统。除系统级服务管理器外，Cantrill 认为最紧迫的战场在于操作系统之下的固件层，当前大量固件仍深陷汇编与 C 语言的泥潭，使用内存安全的 Rust 替代老旧固件已成为全行业基建的重要任务。 Cantrill 强调 Rust 绝非适用于所有领域的万能银弹，对于高度依赖复杂多重所有权指针图的单体内核也难以直接逐行重写；但只要系统软件的核心价值依然是性能与健壮性并重，Rust 及其互操作能力就为构建下一代安全底层基础设施提供了不可替代的技术路径。

## Background 该视频由 YouTube 频道 FunctionalTV 于 2018 年 12 月 10 日发布，记录了 Scale by the Bay 2018 大会的演讲现场。视频简介指出，曾任 Sun 杰出工程师、Solaris/ZFS/DTrace 核心贡献者以及 Joyent CTO 的系统底层老将 Bryan Cantrill，将在此分享他近期上手学习 Rust 的亲身体验与工程洞见。 ## TL;DR Bryan Cantrill 从软件与技术平台的底层“价值观”切入，深入剖析了 C 语言将极致性能置于一切之上的取舍所带来的系统安全隐患，以及 2018 年芯片硬件漏洞危机给底层基础设施带来的惨痛教训。他回顾了系统软件长期依赖工程师肉身走钢丝的痛苦历史，指出 Node.js 等动态语言无法满足系统级健壮性要求。通过对比手写 C 与向编译器妥协的 Rust 代码在 B-tree 重平衡上的基准测试，他展现了 Rust 所有权模型与现代类型系统带来的降维打击。最后，他主张利用 Rust 出色的互操作性开展渐进式重构，并呼吁开发者将 Rust 作为武器投入到与脆弱底层固件的关键战役中。 ## Atmosphere & style Bryan Cantrill 保持了他标志性激情四溢、语速极快且幽默犀利的演说风格，整场演讲充满讽刺自嘲与极具感染力的生动比喻。从将与编译器博弈戏称为“让伍基人赢”，到调侃系统程序员看到代数数据类型如同野蛮人发现自来水，现场笑声与掌声接连不断。整场分享兼具对数十年系统软件工程代价的深沉反思与迎来新工具的破晓振奋感，给听众带来既硬核通透又热血沸腾的现场体验。 ## Bulletin - [02:05](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=125s) 技术决策的本质是核心价值观之间的取舍，当两项优秀特性产生冲突时，平台和语言的选择最终决定了软件演进的方向与社区生态。 - [14:17](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=857s) 2018 年曝光的 Meltdown 与 Spectre 硬件漏洞揭示了微处理器架构长期以性能牺牲安全性的代价，导致上层系统软件的安全防线全面沦陷并迫使工程师投入整年精力修复。 - [27:32](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1652s) 在基准测试中，向编译器妥协写成的 Rust 代码因标准库对 B-Tree 的利用全面超越了精心优化的 C 语言 AVL 树实现，体现出现代多级缓存架构下 DRAM 访问特性的变化。 - [33:04](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1984s) Rust 并非意图全盘推翻重写一切，而是通过高度的 C 互操作性与 unsafe 关键字构建安全沙箱，适合在服务管理软件、固件等关键基础设施中推行渐进式替代。 ## Key takeaways - [00:14](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=14s) Bryan Cantrill 坦言自己作为底层系统程序员，最早是通过 2005-2006 年的 JavaScript 及 Ajax 热潮才真正理解并领悟了闭包和匿名函数等函数式编程概念。 - [02:05](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=125s) 平台与语言的价值观定义了其在面对冲突特质时的优先级排序，认同这些取舍的开发者聚集在一起，会形成强化这些价值观的社区闭环。 - [05:49](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=349s) C 语言诞生的初衷是作为一种非机器特异性的“可移植汇编”，其核心价值序列由极致性能、底层互操作性、可移植性与极简主义主导。 - [09:57](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=597s) OpenBSD 将“安全”作为唯一核心价值，宁可牺牲 50% 的虚拟 CPU 核心并禁用超线程技术，也绝不容忍潜在的侧信道攻击风险。 - [12:36](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=756s) Scala 的核心价值在于高表达力与对庞大 Java 生态的无缝互操作性，其演化方向正是通过精简包袱来简化健壮软件的编写。 - [14:17](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=857s) 系统软件不能随心所欲选择价值观，若底层硬件在性能与安全冲突中牺牲安全，上层软件的一切防御机制都将沦为徒劳。 - [17:11](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1031s) 系统级软件背负着兼容性、可调试性、数据完整性及性能等多项严苛指标，由于性能直接挂钩商业成本，往往成为不可妥协的核心。 - [19:02](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1142s) 能力系统与微内核等诸多优秀的理论操作系统模型在历史上大多折戟沉沙，其根本原因在于无法逾越性能这道残酷门槛。 - [20:32](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1232s) C++ 走向了“反简洁性”极端，其复杂的对象模型和符号修饰导致语言边界外的互操作性变得极其痛苦。 - [22:07](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1327s) C 语言的高性能与健壮性完全建立在工程师个人经验、代码审查和严苛测试之上，编译器本身并未提供足够的安全网。 - [23:20](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1400s) Node.js 追求入门亲和力而隐藏边缘条件的哲学，与追求应对极端异常的系统软件底层价值观存在根本冲突，无法成为系统软件的救星。 - [25:05](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1505s) Rust 的所有权系统在编译期确定内存分配与释放，既消除了运行时垃圾回收的停顿开销，又彻底解决了 C 语言在模块边界上的组合性难题。 - [27:32](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1652s) 由于现代多级缓存使得 DRAM 访问速度等同于新型“磁盘”，Rust 默认采用高缓存局部性的 B-Tree，重平衡效率碾压了传统 C 语言 AVL 树。 - [28:32](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1712s) Rust 拥有代数数据类型、卫生宏以及强约束下的编译器优化，使系统程序员在不放弃性能的前提下获得了高阶函数式语言的严谨表达力。 - [30:20](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1820s) unsafe 关键字并非鼓励危险操作，而是将内存越权和低层系统调用严格限制在微小的可控沙箱内，阻断风险蔓延到整个应用代码。 - [31:37](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1897s) Rust 将生产运行期的调试维护负担逆向推导回开发阶段，开发者与编译器搏斗虽然痛苦，但产出代码的正确性与优雅度极高。 - [33:04](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1984s) 重写整个旧操作系统内核并不现实，但 Rust 非常适合用于渐进式替换用户态关键设施（如 systemd 类服务管理软件）以及不可靠的底层固件。 - [35:07](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=2107s) 任何将极致性能视作不可妥协基石的工程领域（如游戏引擎或高性能计算），都能通过 Rust 获得安全与组合性上的软件工程重构利好。 ## Detailed walkthrough ### [00:14](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=14s) 系统软件程序员在函数式编程专场的“自白”与 JavaScript 启蒙 Bryan Cantrill 开场时风趣地提到，这绝对是他人生中第一次、也很可能是唯一一次站上“函数式编程”的分论坛讲台。作为一名常年深耕系统软件底层的程序员，函数式语言在很长一段时间里根本就不在他的“菜单”上。具有讽刺意味的是，他真正接触并领悟函数式编程，居然是通过 JavaScript——他坦言尽管自己拥有计算机科学学位、本不该找借口，但他确实是在 2006 年深入 JavaScript 时才真正开始欣赏和理解函数式编程。 当时正值 2005 到 2006 年，Web 领域掀起了 Ajax 热潮。Bryan 吐槽 Ajax（Asynchronous JavaScript and XML）是“史上最烂的缩写”：一个缩写词里竟然同时混着连词和缩写，设计极其糟糕。不过，当时大批工程师为了在浏览器里构建复杂的富应用，不得不扎进 JavaScript 中。正是在那时，大家突然震惊地发现：JavaScript 根本不是用来写 `<blink>` 闪烁标签的玩具，而是一门真正的编程语言。Bryan 发现自己开始真正在意并学会了闭包（closure）和匿名函数（lambda）。随后在 Joyent，他们因多种考量重度使用了 JavaScript（如 Node.js 服务端生态），但在系统软件的最深层，工程师们依然缺乏这种强大的编程表现力，长期处于被限制、停滞不前的状态。他认为如今技术界终于迎来了打破这一僵局的转机。 ### [02:05](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=125s) 平台与软件价值观：技术选择背后的取舍 Bryan 强调，随着年龄增长，他越发坚信“价值观（Values）”才是一切工程决策的真正核心。他将“价值观”定义为人们在一堆皆为正面的特性中所做出的取舍与抉择。性能（Performance）、健壮性（Robustness）、可调试性（Debuggability）、可组合性（Composability）、表现力（Expressiveness）等都是公认优秀的特性，没有人会觉得哪一项是垃圾。然而，一个平台或语言不可能全盘兼顾，真正决定其本质的，是在两项优秀特质发生不可调和的冲突时，平台究竟会放弃什么、保全什么。 在开源时代，选择一门编程语言或技术平台，本质上是在选择一个技术社区及其价值观。Bryan 结合自身经历警告道，如果你仅迷恋某项技术本身，但其社区的价值观与你背道而驰，最终这门软件演进出的形态也必然会偏离你的价值观。核心价值观还会吸引志同道合的人，形成强大的自我强化闭环：认同这些价值观的人涌入社区，进而极力捍卫并延续这些价值观。 ```mermaid flowchart TD accTitle: 核心价值观的自我强化闭环 accDescr: 核心价值观驱动技术决策，吸引认同该理念的开发者，进而在社区中捍卫并强化该价值观 subgraph PlatformCycle["价值观正向循环"] A["核心价值观取舍<br/>(在冲突中确立优先级)"] --> B["塑造软件特性与设计哲学"] B --> C["吸引志同道合的开发者与社区"] C --> D["开发者捍卫并巩固既有取舍"] D --> A end ``` Bryan Cantrill 在讨论这一现象时明确断言：“The older I get the more I believe that that values are really core to the decisions that we make.” ### [05:49](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=349s) C 语言的诞生背景与核心价值观 为了具体剖析不同技术的价值观差异，Bryan 回溯了 C 语言的演进历史。大众常误以为 C 语言和 UNIX 是同时在“产道”里诞生的双胞胎，但事实并非如此：UNIX 最初完全是用汇编语言写成的。当时虽然存在 B 语言，但由于执行速度慢，B 语言仅用于操作系统外围极少量的辅助模块。贝尔实验室的先驱们迫切需要一种高级结构化语言，使他们免于在汇编中编写整个操作系统。因此，C 语言诞生的初衷非常明确——它本质上就是一个“更好的汇编语言”，即一种不针对特定机器架构的“可移植汇编”（portable assembly）。 基于这一背景，C 语言确立了极度明确的核心价值观： - **性能（Performance）**：作为无可撼动的首要目标，在表现力与性能产生剧烈冲突的年代，C 毫不犹豫地选择了极致性能。 - **互操作性（Interoperability）**：由于直接建模机器硬件，C 被设计为能与机器上运行的任何底层指令（尤其是汇编语言）无缝对接。 - **可移植性（Portability）**：跨越不同硬件架构提供统一抽象。 - **极简主义（Simplicity）**：C 保持了极为克制的审美，仅在实现 UNIX 所必需时才扩充特性。例如 C 最初甚至没有结构体（struct），因为汇编本身就没有结构体；直到开发操作系统确实迫切需要组织数据时，才谨慎地加入了结构体，并随即停止过度扩展。 关于 C 语言的本质，Bryan Cantrill 总结道：“The birthplace of C is we want effectively a better assembly we want a non machine specific assembly and that's what C is.” ### [08:18](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=498s) 字母语言的极端异类：Arthur Whitney 与 K 语言的极致精炼 谈完单字母语言 B 和 C，Bryan 顺带提到了金融高频交易领域知名但小众的 K 语言（及其后继者 Q 语言）。K 语言虽然与底层系统软件无关，但其创始人 Arthur Whitney 的技术哲学堪称极致表现力与极简主义的典范。Bryan 调侃 Arthur 仿佛生活在“另一个精神位面”：Arthur 在 4 岁时就跟随邻居 Ken Iverson（APL 语言之父）学习 APL，并始终怀揣一个坚定不移的信念——他能教会任何一个 4 岁小孩写 APL。Bryan 笑着回忆说，自己孩子 4 岁时 Arthur 曾热情邀请他把孩子送去学 APL，但 Bryan 当场拒绝并表示这绝对会是一场灾难：“I knew for a fact could not be taught APL.” 在 K 语言的世界里，核心价值观几乎完全倒向了极致的表现力与字符压缩。Arthur 眼中的程序美学，就是用尽可能少的字符实现完整的程序逻辑。Bryan 开玩笑说，不知道 Arthur 是不是打心底里觉得每多敲一个字符都会遭受残酷的惩罚，这种对极短代码的狂热追求塑造了 K 语言独一无二、难以模仿的代码风格与平台特质。 ### [09:57](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=597s) 极端取舍与清晰价值：从 K 语言、OpenBSD 到极简的 AWK 各种编程语言和操作系统在价值取向上展现出截然不同的极端形态。以用于金融市场高频交易的数组编程语言 K 为例，它的设计者不断追求极致的代码密度，代码被压缩得密不透风，毫无可读性可言。Bryan Cantrill 调侃道，如果你的年龄和我差不多，就会记得当年用拨号调制解调器上网时，母亲突然拿起座机听筒传来的那一串刺耳线路杂音——而 K 语言的代码看起来就像是那一串杂音编译出来的产物。但从另一个角度看，它又是美丽的：它完全抛弃了可维护性和可读性，全心全意只追求极致的表达力与极高吞吐的性能。 与这种语言相比，操作系统领域的 OpenBSD 则走向了另一种绝对的纯粹。OpenBSD 的核心价值列表中只有一项，那就是“安全”（Security）。Bryan 强调这绝非贬义，事实上，一个系统能如此坦率和透明地表明自己的立场，反而让人感觉无比清晰通透。为了安全，OpenBSD 团队哪怕牺牲大量性能也在所不惜；当他们认定英特尔的超线程（Hyper-Threading）技术在任何速度下都不安全时，便毫不犹豫地直接将其禁用。即便用户因此凭空损失了一半的虚拟 CPU 核心，OpenBSD 的态度也很明确：那些核心从一开始就存在侧信道攻击漏洞，从未真正安全过。这种对自身价值的偏执坚持是完全合理且令人钦佩的。 最后是 AWK，一种为了“快速编写小程序”而生的极简工具。Bryan 表示自己每天都要写三到四行 AWK 单行命令来快速解决问题。AWK 由阿尔弗雷德·艾侯（Alfred Aho）、彼得·温伯格（Peter Weinberger）和布莱恩·柯林汉（Brian Kernighan）共同发明，其配套著作《AWK 编程语言》堪称编程语言文档的绝佳典范。全书只有大约 130 页，排版优美，只需花两个小时就能完全读完并彻底掌握整门语言。它极其简单、亲切且直截了当，展现了小而美工具的独特价值。 > “OpenBSD the operating system: security, end of core values. There is no other core value in OpenBSD and that's not—I'm not being pejorative, it's actually incredibly clarifying when you have a system that is so upfront and transparent about: this is what we care about.” —— Bryan Cantrill - **K 语言的设计取舍**：彻底放弃可维护性与可读性，将极致的表达力和运算性能置于一切之上。 - **OpenBSD 的极致安全观**：宁可损失 50% 的虚拟核并禁用超线程，也要斩断侧信道攻击风险。 - **AWK 的入门门槛**：全书仅 130 页左右，两小时即可通读并完全掌握，被 Bryan 赞为语言文档的教科书级标杆。 --- ### [12:36](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=756s) 审视编程语言的核心价值观：以 Scala 为例 程序员之所以被某种技术或语言深深吸引，根本原因往往在于其底层所秉持的核心价值观与自身产生了共鸣。Bryan 坦诚自己从未写过一行 Scala 代码，并打趣道自己特意在幻灯片上打了个问号，好在台下听众因为观点分歧向他扔椅子时能有个台阶下。不过，梳理 Scala 的核心价值依然是一个极佳的思维练习。在 Bryan 看来，Scala 的基石在于两点：强大的表达力（Expressiveness）以及无与伦比的互操作性（Interoperability）。 Scala 的诞生初衷正是为了无缝融入庞大的 Java 生态系统。Bryan 回忆起 2004 年前后听 Martin Odersky 最初介绍 Scala 的演讲，当时的核心震撼就在于：开发者可以在一门提供数据完整性、健壮性、表达力和可组合性的全新语言中，直接复用现有的全部 Java 类库。这并不是说 Scala 不在乎性能或其他维度，而是在面临两难权衡时，互操作性与表达力始终占据首位。在本次大会前一晚的小组研讨中，Martin Odersky 谈到 Scala 的未来演进方向正是让编写健壮软件（robust software）变得更加简单，为此 Scala 正在剔除一些不再符合这些核心价值的历史包袱（例如 XML 字面量语法）。这种对语言特性的精简与取舍，再次印证了核心价值观对软件演进的主导作用。 > “The whole point of Scala is to be able to interact with the Java ecosystem at large. That's a very core principle to me, that's a core value.” —— Bryan Cantrill ```mermaid flowchart TD accTitle: Scala Core Values Flow accDescr: 展示 Scala 如何基于 Java 生态互操作性与语言表达力构建健壮软件 subgraph CoreValues["Scala 核心价值主张"] interop["互操作性 (Interoperability)<br/>与 Java 生态无缝对接"] expr["高度表达力 (Expressiveness)<br/>高组合性与类型安全"] end subgraph LanguageEvolution["语言演化实践"] clean["精简陈旧特性<br/>(如移除 XML 字面量)"] robust["提升代码健壮性<br/>(Robust Software)"] end interop --> robust expr --> robust robust --> clean ``` --- ### [14:17](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=857s) 2018 年的灾难之年：当底层硬件的价值取向背叛了安全性 对于底层的系统软件（操作系统、底层基础设施）而言，其核心价值不能任由开发人员随意发挥，而是被上层软件乃至全行业的使用者所严苛限定的。如果一个操作系统动不动就发生内核崩溃（panic），或者缺乏安全与健壮性，它就绝不可能在现实世界中生存。更残酷的现实在于：底层的软硬件一旦缺失了某项价值，依赖于它的上层软件无论做多少努力，都无法凭空拥有这项价值。 Bryan 将 2018 年形容为他职业生涯中“可怕的一年”（annus horribilis）。2018 年 1 月 2 日，他在 Hacker News 上看到有人正在逆向工程提交给 Linux 内核的补丁，隐约察觉到英特尔 CPU 存在极其严重的硬件漏洞（即席卷业界的 Meltdown 与 Spectre）。随后的事实证明，微处理器芯片在过去的架构设计中，始终将“性能”凌驾于“安全”之上，在预测执行和推测执行中走捷径。Bryan 坦言我们所有人都是这一决策的同谋，因为市场始终在疯狂索取更强的计算性能。然而，底层硬件为了性能抛弃安全的代价是惨痛的：由于超线程天然存在微架构侧信道隐患，或者在没有内核页表隔离（KPTI）的情况下内核内存被窥探，上层操作系统和系统软件的安全性瞬间瓦解。系统工程师们不得不取消 2018 年原定的全部计划，将一整年的时间用于修补漏洞，仅仅为了让系统的安全性退回到 2017 年 12 月 31 日所假想的状态。 > “2018 has taught us that security was ultimately subservient to performance in the design of the microprocessor—and we were all complicit in that, by the way... we discovered that that very lowest substrate, because it chose performance over security at some very key and implicit junctures, we ended up with a substrate itself above it in the operating system, the system software, that now lost security as a value.” —— Bryan Cantrill - **基础底座的价值传导**：底层硬件若在安全性上失守，上层构建的任何防御措施都将沦为徒劳。 - **2018 年芯片安全危机**：Meltdown 与 Spectre 揭示了处理器为了追求极限性能而在硬件隔离上所做的妥协。 - **工程代价**：系统软件工程师被迫花费整整一年时间做漏洞防御与性能折损弥补，只为找回原以为早已拥有的安全基准。 --- ### [17:11](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1031s) 系统软件无法妥协的严苛价值清单 系统软件必须承担极为繁重的价值包袱，其核心指标几乎不容有失：它必须具备向下兼容性，不能因为升级 CPU、操作系统或数据库而直接搞崩上层应用；必须具备高度的可调试性（debuggability），让开发者能在生产环境出现故障时洞察底层根因；必须坚守数据完整性，对静默数据损坏零容忍；必须拥有极强的弹性、健壮性与稳定性；同时，由于系统软件属于底层基础设施，它必须具备全面性（thoroughness），为形形色色、各不相同的业务场景提供坚实的通用支撑。 在这份清单中，最让人又爱又恨的价值就是“性能”。Bryan 引用了他在 Sun Microsystems 的前同事、已故传奇工程师 Roger Faulkner 的名言：“性能是万恶之源”（performance is the root of all evil）。从理想主义角度看，如果工程师们不再在乎软件运行快慢，很多架构设计会变得极其简单；但现实世界的残酷商业逻辑决定了性能直接挂钩服务器成本和经济效益。在很多场景下，哪怕某款系统软件只比竞品快 2%，为了压榨出这微小的 2% 优势，工程师就必须经历极其痛苦残酷的代码调优与底层重构。最后，Bryan 强调了透明性（transparency），过去行业通过开源逐步打破了专有封闭软件的黑盒，但如今随着公有云的兴起，许多基础设施再次变成了不透明的专有云服务，这一趋势值得所有从业者深思。 > “The late great Roger Faulkner, I worked with at Sun Microsystems for a long time, would say that performance is the root of all evil. And he's right, performance is the root of all evil—if we are happy with our systems not performing well, things get a lot easier.” —— Bryan Cantrill | 价值维度 | 系统软件的核心要求 | 违反该价值的后果 | |:--- |:--- |:--- | | **兼容性 (Compatibility)** | 处理器、OS、数据库升级不能破坏已有代码 | 阻碍软件升级生态，破坏用户信任 | | **可调试性 (Debuggability)** | 必须在生产环境可观测、可追踪异常根因 | 线上事故发生时沦为“黑盒”，排障成本不可控 | | **完整性 (Integrity)** | 杜绝静默数据损坏与内存污染 | 用户数据丢失或计算结果错误，产生灾难性后果 | | **性能 (Performance)** | 极限压榨硬件周期，严苛控制资源浪费 | 直接恶化运行经济成本，丧失市场竞争力 | | **全面性 (Thoroughness)** | 提供通用且完备的系统底座，而非脆弱的专用工具 | 无法承载多样化的业务负载与边界场景 | | **透明性 (Transparency)** | 源码与运行机制清晰可查，抵御专有黑盒 | 架构被专有云厂商锁定，失去底层控制权 | ### [19:02](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1142s) 系统软件对性能的绝对妥协与历史坟场 Bryan Cantrill 通过比对系统软件所必需的价值观与 C 语言的核心价值观，指出了一个残酷的事实：在两者的交集中，唯一重合的价值观只有“性能”（Performance）。他半开玩笑地提到前几年去世的 Roger Needham（或指其对系统架构的洞见），调侃其仿佛正在坟墓中幽灵般地看着大家，因为性能在此时真正成了“万恶之源”。无论工程师多么希望系统拥有透明度、安全性或健壮性，残酷的现实是性能凌驾于一切之上。市场和现实绝不会接受一个在所有其他指标上都极佳、唯独性能拉胯的底层系统。 为了证明这一点，Bryan 让大家去看一看操作系统历史的“坟场”。在计算机科学发展的长河中，涌现过无数设计精妙的架构，比如基于能力（Capability-based）的安全系统、微内核（Microkernel）系统等，它们在理论模型上极具前瞻性，但最终全都折戟沉沙，倒在了性能这个最严苛的标准面前。Bryan 坦言自己也是个偏执的内核拥趸（曾长期维护和分叉 UNIX），但他不得不承认：凭借 C 语言，业界虽然磕磕绊绊地实现了高性能系统，但这一过程伴随着无尽的痛苦。 > “The reality we might not like that, but we cannot accept a system that is better in all of these other attributes but suffers in terms of performance.” —— Bryan Cantrill - 价值观交集收敛：系统软件需求与 C 语言特性的重叠点仅剩性能一项。 - 历史系统的教训：能力系统与微内核系统大都在性能这一关键短板上遭遇失败。 --- ### [20:32](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1232s) C++ 的抉择：反直觉的复杂性与互操作性深渊 Bryan 转向了 C 语言的自然接班人——C++。如果给 C++ 绘制一份价值观画像，他认为必须把“简洁性”（Simplicity）彻底划掉，甚至应该用粗线涂掉，因为 C++ 已经走到了“反简洁性”（Anti-simplicity）的极端。在表达能力（Expressiveness）被拔高的同时，C++ 实际上牺牲了至关重要的“互操作性”（Interoperability）。虽然名义上 C++ 是一个“更好的 C”，并且至今依然能在某种程度上编译 C 代码，但这一特性随着时间推移重要性在不断下降，真正的噩梦发生在语言边界之上。 当非 C++ 编写的组件试图与 C++ 代码协同工作时，互操作性会变得极其痛苦。这种摩擦从底层的符号修饰（Name Mangling）机制开始，一路向上蔓延。如果开发者在编写 C++ 代码之初没有极其明确地为其设计 C 兼容接口，外部世界就极难调用它。这直接导致系统软件编程语言的核心价值与生产环境的实际诉求产生了巨大断层：一面是软件工程必须追求的稳定性、安全性和健壮性；另一面则是现有语言对性能的孤注一掷与对安全防护的彻底放任。 ```mermaid flowchart TD accTitle: C and C++ Trade-offs in System Software accDescr: 比较 C 和 C++ 在系统软件中所坚持的价值观与面临的妥协缺陷 subgraph LangC["C 语言价值观与代价"] C_Val["核心价值：极致性能"] C_Cost["代价：缺乏安全网、组合性极差、高度依赖人工心智"] end subgraph LangCPP["C++ 价值观与代价"] CPP_Val["核心价值：性能 + 极高表达力"] CPP_Cost["代价：反简洁性、符号修饰、跨语言互操作性极度痛苦"] end subgraph SysReq["系统级软件的真实需求"] Req["稳定性 / 健壮性 / 安全性 / 性能 / 组合性"] end LangC -->|"唯一交集仅为性能"| SysReq LangCPP -->|"复杂性爆炸与互操作阻碍"| SysReq ``` - C++ 的设计取舍：以牺牲简洁性为代价换取表达能力，导致语言体积与认知负担急剧膨胀。 - 互操作性壁垒：符号修饰及对象生命周期模型的差异，导致非 C++ 系统模块与 C++ 库对接成本极高。 --- ### [22:07](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1327s) C 语言开发如走钢丝与 Node.js 救世幻想的破灭 回顾整个系统软件生态，Bryan 承认业界写出了能跑的系统，在一定程度上兼顾了健壮与安全（甚至在 2017 年 12 月 31 日 Spectre/Meltdown 漏洞曝光前，大家都还盲目地以为系统足够安全）。然而这一切都是靠极其沉重、痛苦的代价换来的。工程师们花费数十年编写专门的定制化工具链，全凭个人经验走钢丝。Bryan 坦言自己写 C 代码时有信心不出现悬空指针和内存解引用错误，因为他一辈子都在与 `malloc`、`free` 和动态数据结构打交道，但这种安全完全建立在程序员个人水平、高压代码审查和严苛测试之上，语言本身没有提供任何安全网，就像一个只要大家顶礼膜拜“性能神坛”就可以为所欲为的蒙特梭利幼儿园。 因为这种“成功不是因为语言，而是克服了语言缺陷才取得”的痛苦，Bryan 曾陷入长期的绝望。在 Joyent 期间，他一度抱有极大的幻觉，认为 Node.js 会拯救全人类。当时外界嘲笑“那不过是 JavaScript”，而他心中还曾幻想它能进化成一种编写健壮服务端软件的现代动态语言。但事实证明外界是对的：它真的“就只是 JavaScript”。JavaScript 的核心价值观是开发速度（Velocity）和极强的平民化亲和力（Approachability），让数以万计的初学者能无门槛上手。但这种为了亲和力而隐藏边缘条件的做法，与追求绝对健壮的系统软件底层哲学背道而驰，这两种价值观存在着无法调和的根本冲突。 > “We've succeeded despite the language, not because of it.” —— Bryan Cantrill - 人力构筑的防线：C 语言的安全与稳定性完全依赖顶级开发者的肌肉记忆与测试工具，编译器本身毫无约束。 - Node.js 的定位错位：JavaScript 的核心诉求在于降低入门门槛（Approachability），而系统软件的首要诉求在于应对极端边缘情况的健壮性（Robustness）。 --- ### [25:05](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1505s) 初探 Rust：所有权系统与“让伍基人赢”的初体验 正当对新语言心灰意冷之际，Rust 逐渐走进了 Bryan 的视野。虽然 Rust 早在 2006 年前后就已起步，但经过漫长打磨，它所构建的所有权（Ownership）机制让 Bryan 产生了强烈的“Rust 好奇心”（Rust curious）。Rust 提出了一个全新的契约：程序员与编译器密切配合，明确每块内存的所有权流转；编译器施加严苛的限制，而开发者要保证“在编译器报错时不至于当场哭出来”。通过这种机制，编译器能在没有垃圾回收器（GC）介入的情况下，在编译期精准决定内存的分配与释放，一举实现了 GC 语言般的内存动态管理体验与显式内存管理的高性能。 更关键的是，Rust 解决了 C 语言最致命的痛点——可组合性（Composability）。在 C 语言中，哪怕开发者自身是内存管理大师，一旦调用第三方库，边界处的隐式或显式内存分配与释放稍有疏漏，就会引发灾难性的内存泄漏或内存破坏；为了安全，C 程序员往往只能将数据结构层层嵌套，写出次优的代码。为了验证 Rust，Bryan 决定将一段自己此前用手写高度优化的 C 代码重写为 Rust。在与编译器痛苦拉锯、擦干眼泪之后，他总结出了一条与 Rust 相处的真理：**“让伍基人赢”（Let the Wookiee win，出自《星球大战》典故）**——如果 Rust 强迫你用某种特定方式写，顺着它做才是明智之举。 ```mermaid flowchart LR accTitle: Rust Ownership and Memory Contract accDescr: 展示 Rust 程序员与编译器协作管理内存的过程及带来的双重优势 subgraph DevCompilerCoord["所有权契约协作"] Dev["开发者遵循规范"] <-->|"编译期所有权校验"| Comp["Rust 编译器"] end subgraph EngineBenefits["核心产出优势"] Comp --> SafeAlloc["精准插入内存分配/释放<br/>(无运行时 GC 开销)"] Comp --> SafeComp["跨模块安全组合<br/>(消除第三方库边界内存悬垂)"] end SafeAlloc --> Result["具备 C 的显式性能 + 动态语言的安全感"] SafeComp --> Result ``` - 所有权核心契约：编译器在编译阶段完全掌握引用的生存周期，免除运行时 GC 暂停，同时封堵内存泄露途径。 - 解决组合性痛点：避免 C 语言在模块边界处因跨团队认知差异导致的“谁负责释放内存”的隐患。 --- ### [27:32](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1652s) 反直觉的基准测试：B 树对 AVL 树的性能逆袭 为了让代码顺利通过编译，Bryan 在重写时甚至放弃了性能考量，采用了一种自认为“明显次优”的方式妥协实现，心想“就算性能稀烂，先让这玩意儿跑起来再说”。然而，当测试程序真正运行起来时，结果令他目瞪口呆：这段仓促写就、向编译器妥协的 Rust 代码，其实际运行性能竟然全面超越了他精心打磨、手写优化的 C 语言原版。 Bryan 迅速对程序进行性能剖析和拆解，找到了性能逆袭的核心原因。该程序的核心工作负载是极度频繁地对二叉树进行重平衡（Rebalancing）。在编写 C 语言版本时，他使用了系统编程中最为经典的 AVL 树实现（基于数十年来沉淀的成熟模板）；而在 Rust 生态中，标准库与主流基础原语广泛采用的是 B 树（B-Tree）。在传统计算机科学教育中，B 树通常只在数据库管理系统或涉及磁盘 I/O 的场景中讨论，但 Rust 团队敏锐地捕捉到了现代硬件架构的变化：在现代 CPU 极其多级的缓存体系下，DRAM 内存本身就已经慢得等同于一块“磁盘”。B 树节点对缓存行（Cache Line）的高度利用，使得其在纯内存操作中的重平衡效率彻底击败了传统的 AVL 树。 > “I ran it and it outperformed my C. It's like, what? How did that happen?” —— Bryan Cantrill - 逆直觉的基准测试：即使采用向编译器妥协的“次优”编码，Rust 版本的综合性能依然击败了手写优化的 C 版本。 - 架构层面的认知升级：Rust 将 DRAM 视为新型“慢速磁盘”，利用 B 树结构极大优化了现代 CPU 缓存命中率，在树重平衡场景下彻底碾压传统 AVL 树。 ### [28:32](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1712s) Rust 的核心价值观：性能、互操作性与语言特性的降维打击 Bryan Cantrill 详细分析了自己用 Rust 编写的代码击败 C 语言实现的深层原因。在数据结构选型上，B-tree（B树）其实比红黑树更合理，但由于 B-tree 手动实现的难度极高，C 程序员往往望而却步；而在 Rust 中，标准库提供了现成的实现，开发者无需关心底层细节即可直接调用。更重要的是，Rust 编译器能执行许多 C 编译器因指针别名等限制而无法实施的深度优化。现场有人质疑这是否只是 GCC 的优化问题、若换用 Clang 是否会反超，Cantrill 幽默地反驳道：“Clang 不会从根本上改变我那段 C 代码的物理法则”（“clang is not gonna fundamentally change the physics of my C which it doesn't”）。实测表明虽然 Clang 表现略好一点，但 Rust 依然胜出。这一对比深刻展现了 Rust 的核心价值：性能依然是宇宙的中心，但它同时带来了 Scala 等高级函数式语言早已拥有、而系统级编程长期欠缺的高级表达能力与组合性（composability），兼具安全性、严谨性、健壮性、完整性以及至关重要的互操作性（interoperability）。 ```mermaid flowchart TD accTitle: Rust 与 C 的系统级特性对比 accDescr: 展示 Rust 如何结合底层性能与高层语言特性 subgraph CoreValues["核心价值观"] Perf["极致性能 (Performance)"] InterOp["C 互操作性 (Interoperability)"] Safety["类型与内存安全 (Safety & Rigor)"] end subgraph ModernFeatures["现代语言特性支持"] ADT["代数数据类型 (Algebraic Types)<br/>精确严谨的错误处理"] HMac["卫生宏 (Hygienic Macros)<br/>超越 C 预处理器的元编程"] Unsafe["unsafe 关键字<br/>将内存放权限制在极小沙箱"] end CoreValues --> ModernFeatures ``` Cantrill 进一步强调，Rust 与其他类似语言最大的不同在于它对互操作性的极致追求：“Rust 并不渴望用 Rust 重写一切，Rust 致力于与那些已经存在的系统协作”（“rust does not aspire to rewrite everything in rust rust is trying to cooperate with those systems that already exist”）。他接着自嘲系统程序员在发现代数数据类型（Algebraic Data Types）时的表现，就像野蛮人突然发现自来水龙头能流出净水一样大呼小叫，对台下的 Scala 听众来说简直是“班门弄斧”；然而代数数据类型在系统错误处理上的紧凑与健壮性确实令人惊叹。此外，Cantrill 盛赞了 Rust 的卫生宏（Hygienic Macros，他开玩笑说自己直到写 Rust 才学会 hygienic 这个词怎么拼，以前在 C 语言中全靠宏预处理器死撑）、出色的 C 语言外部函数接口（FFI），以及 `unsafe` 关键字。关于 `unsafe`，他抛出了一个即兴比喻：它就像犯人的假释期或是“与内存的探监幽会”（“a conjugal visit with your memory”），说完自己都忍不住失笑想要撤回。但正是这种将潜在危险严格隔离在微小代码块中的设计，既释放了系统级黑魔法的潜力，又避免了内存不安全污染整个应用架构。 - **B-tree 对决红黑树**：B-tree 在缓存局部性上优势显著，但手写难度极大；Rust 零成本抽象使开发者能零门槛利用其算法红利。 - **编译器优化空间**：由于拥有更严格的借用与别名保证，Rust 编译器能做出比 C（无论是 GCC 还是 Clang）更激进的指令级优化。 - **代数数据类型（ADT）的价值**：为底层软件带来了极致紧凑、严谨且富有表达力的错误处理范式。 - **卫生宏与 FFI**：摆脱了 C 预处理器文本替换的诸多安全漏洞，同时保留了系统编程所需的元编程能力与 C 无缝衔接能力。 --- ### [31:37](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1897s) 认知负荷的前置：与编译器搏斗的痛苦与馈赠 谈及 Rust 的开发体验，Cantrill 深入剖析了 Rust 带来的“认知负荷转移”机制。Rust 的精妙之处在于将软件在生产环境运行时的认知负担与维护噩梦，逆向推回给了开发阶段的程序员。对于线上运维和系统负责人来说这是天大的喜讯，但对于正在敲代码的开发者而言，这意味着巨大的挫败感——你会纳闷为什么会有如此庞杂的事情需要思考。编译器对生命周期和类型检查近乎病态的吹毛求疵（pedantic），常常让程序员误以为自己正在与一个错误的编译器展开毫无意义的争吵；然而无数事实证明，最后败下阵来的开发者总会震惊地发现：“Rust 实际上是对的，这里确实存在一个真实潜在的问题”（“rust is right actually rust is right there's an actual real issue here”）。 Cantrill 现场援引了《Programming Rust》书中的一段经典名言来概括这种奇妙的开发心理状态：开发者往往会经历一段与编译器异常激烈的交锋争吵，可一旦这段折磨结束，最终落成的代码不仅运行得极其完美流畅，而且看起来优雅轻盈得仿佛写出来不费吹灰之力——然而代码本身并不会记录开发者在打磨出这件艺术品时所发出的绝望惨叫。这种机制也决定了 Rust 的适用边界与隐患：在重新实现那些已经稳定运行、且充斥着复杂多重所有权（multiple ownership）的数据结构的既有系统（例如操作系统内核）时，Rust 严苛的所有权模型可能会让重构变得极度痛苦和残酷。 --- ### [33:04](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1984s) 破晓时分：系统级软件的渐进式重写与固件之战 尽管全面重写老旧操作系统内核并非 Rust 的最佳切入点，但 Cantrill 指出，正是 Rust 将互操作性和性能置于核心价值观的定位，为现代系统工程开辟了一条崭新的道路。系统架构师可以复制当年普及 C 语言的路线——采取渐进式迭代策略，在不动整个底盘的前提下，一块一块地将局部核心组件替换为 Rust 实现，正如 Scala 社区无缝融合 Java 生态一样。操作系统的外围存在着浩瀚的用户态关键基础设施，它们是 Rust 绝佳的演兵场。Cantrill 明确表示：“如果我今天在编写 systemd……如果有人要编写一个用户级设施来作为服务管理软件，我绝对会用 Rust 来写”（“if one were writing a user level facility to manage software as a service I would write that in rust absolutely”）。 更为关键的战场则隐藏在全人类视线之外的微观世界——底层固件（Firmware）。Cantrill 慷慨陈词，将当下的技术困局定性为一场阵营分明的战争： > “我一直很喜欢说一句话，而且我对此深信不疑：我们正在与固件交战。这是全人类与固件的战争，每个人都必须选边站队。”（“I've been fond of saying but I believe it fervently that we are engaged in a war with firmware it is humanity versus firmware and everyone needs to pick a side.”） 那些深埋在主板与芯片内部、至今仍在用纯汇编或不可靠的 C 语言书写的固件程序，是造成各类系统黑天鹅事件的温床。用 Rust 替换这一层脆弱地基不仅切实可行，而且迫在眉睫。Rust 社区常说“我们理应拥有美好的事物”（we can have nice things），它的核心价值观与系统软件严苛的要求高度契合。虽然它绝非万能银弹，亦无需强行套用到所有应用场景，但对于追求极致性能与绝对稳健的系统级工程师而言，Rust 带来了前所未有的解放与创造力。 --- ### [35:07](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=2107s) 现场问答：mmap 的不安全封装与跨领域的价值映射 在演讲尾声的提问环节，观众就 C 交互安全性与 Rust 的应用外延向 Cantrill 提问。一名观众询问在调用 C 库或操作系统低级接口时，Rust 如何保障安全边界。Cantrill 以 Unix 系统调用 `mmap` 为例说明：在系统编程中，直接将内核或文件对象映射到进程虚拟地址空间本身就是打破类型系统规则的操作，因此在 Rust 中它必然被归类为 `unsafe` 操作。Rust 的伟大之处不在于彻底消灭底层系统本身的危险操作，而在于利用语言约束将潜在的不可控因素封印在一个个极小的安全封装盒内。它强制让开发者明确感知风险的存在，有效阻断了内存毒素向整个上层代码库曼延。 随后，另一位与会者提问 Rust 是否能超出传统系统软件的边界，渗透到游戏引擎或通用高性能计算库等领域。Cantrill 给予了无比坚决的肯定，并指出了 Rust 的通用评判法则：“任何这些价值观至关重要的领域，Rust 都会有一席之地；特别是当性能是你首要选择的时候”（“any place where these values are important Russ is gonna have a place and in particular where these are the choices you want to make and in particular particular where performance is the is your top choice”）。只要一个工程领域将严苛的执行效率视作不可妥协的基石，Rust 就能凭借其无垃圾回收的确定性与强健的工程组织力，成为重构该领域软件工程实践的终极利器。 ## Notable quotes > [02:05](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=125s) The older I get the more I believe that that values are really core to the decisions that we make. — Bryan Cantrill > [05:49](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=349s) The birthplace of C is we want effectively a better assembly we want a non machine specific assembly and that's what C is. — Bryan Cantrill > [19:02](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1142s) The reality we might not like that, but we cannot accept a system that is better in all of these other attributes but suffers in terms of performance. — Bryan Cantrill > [28:32](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1712s) rust does not aspire to rewrite everything in rust rust is trying to cooperate with those systems that already exist — Bryan Cantrill > [33:04](https://www.youtube.com/watch?v=2wZ1pCpJUIM&t=1984s) 我一直很喜欢说一句话，而且我对此深信不疑：我们正在与固件交战。这是全人类与固件的战争，每个人都必须选边站队。 — Bryan Cantrill ## Mentioned Bryan Cantrill, Joyent, Sun Microsystems, Solaris, ZFS, DTrace, Rust, C, C++, JavaScript, Node.js, Scala, Martin Odersky, Arthur Whitney, Ken Iverson, K, Q, APL, OpenBSD, AWK, Alfred Aho, Peter Weinberger, Brian Kernighan, Roger Faulkner, Roger Needham, Linux, Intel, Meltdown, Spectre, systemd, B-Tree, AVL 树, Clang, GCC ## Video description This talk video is a node in devreal.ai, the developer community graph. It connects to: Talk: Rust and Other Interesting Things — https://devreal.ai/t/181116-rust-other-interesting-things-scale-by-the-bay Speaker: Bryan Cantrill — https://devreal.ai/n/bryan-cantrill Company: Joyent — https://devreal.ai/c/joyent Event: Scale by the Bay — https://devreal.ai/e/181114-scale-by-the-bay-conference Explore these connections and related videos, photos, speakers’ blogs and podcasts, and other By the Bay networks. ----- Bryan, the CTO of Joyent, and a core contributor to Solaris, ZFS, and DTrace, formerly a Distinguished Engineer at Sun, has recently picked up Rust. He'll share his experience with us. [Source](https://www.youtube.com/watch?v=2wZ1pCpJUIM)

[2:05] Bryan Cantrill: The older I get the more I believe that that values are really core to the decisions that we make. [5:49] Bryan Cantrill: The birthplace of C is we want effectively a better assembly we want a non machine specific assembly and that's what C is. [19:02] Bryan Cantrill: The reality we might not like that, but we cannot accept a system that is better in all of these other attributes but suffers in terms of performance. [28:32] Bryan Cantrill: rust does not aspire to rewrite everything in rust rust is trying to cooperate with those systems that already exist [33:04] Bryan Cantrill: 我一直很喜欢说一句话，而且我对此深信不疑：我们正在与固件交战。这是全人类与固件的战争，每个人都必须选边站队。

[2:05] Bryan Cantrill: If the community doesn't reflect your values, you will find that the software will come to not reflect your values as well. [28:32] Bryan Cantrill: Rust does not aspire to rewrite everything in Rust; Rust is trying to cooperate with those systems that already exist. [33:39] Bryan Cantrill: I've been fond of saying, but I believe it fervently, that we are engaged in a war with firmware: it is humanity versus firmware, and everyone needs to pick a side.

[0:14] good morning everybody um it's great to [0:17] be here I this is definitely the first [0:19] time maybe the only time in my life that [0:22] I'm in the functional programming track [0:23] that is definitely a first so it's [0:27] exciting because often on honestly [0:30] functional languages have not really [0:32] functional programming has not really [0:34] been on the menu for me as a system [0:37] software programmer it kind of actually [0:39] entered the menu ironically enough with [0:40] JavaScript I mean I'm embarrassed to say [0:42] this but I I really I mean I yes my [0:46] degrees in computer science so there's [0:48] no real excuse for this but I didn't [0:50] really appreciate or learn functional [0:53] programming until implanting in [0:54] JavaScript in 2006 so I hopefully I'm in [0:57] kind of a safe space where I can confess [0:59] that to you but um and actually it was [1:02] funny for those of you who weren't [1:04] around at that time to tell it was kind [1:05] of a weird time because we had this [1:08] thing called Ajax asynchronous [1:10] JavaScript and XML worst acronym ever [1:13] like you can't have one of the letters [1:15] be a conjunction another be an [1:16] abbreviation of a terrible terrible an [1:19] idea or a good idea but of a terrible [1:21] abbreviation terrible acronym and a [1:23] bunch of us kind of simultaneously were [1:25] waiting in the JavaScript in late 2005 [1:26] 2006 because we're trying to actually [1:28] build these like interesting programs on [1:30] the browser and discovering like oh my [1:32] god that's a real language here in terms [1:33] of JavaScript it's not just for blank [1:34] tags like I'm actually doing interesting [1:36] things and I actually like oh my god I [1:38] actually I I'm learning what a closure [1:41] is I'm actually I am appreciating a [1:43] lambda I'm actually appreciating this [1:44] stuff so that was great um but in [1:47] JavaScript has been great but and we've [1:50] used to Detroit for a bunch of different [1:52] reasons but the truth is that in the [1:54] deeper parts of system software we have [1:56] not really had that kind of power that [1:58] that programmatic power we've proven [2:00] kind of stuck and I think we're about to [2:03] get unstuck and I want to kind of [2:04] explain what what I'm seeing there I [2:05] want to talk first about about platform [2:08] values and software values because the [2:10] older I get the more I believe that that [2:13] values are really core to the decisions [2:16] that we make so what do I mean by by [2:19] values so values are positive traits [2:23] that you are choosing amongst [2:26] so we all that there are lots of kind of [2:28] positive things but our own individual [2:31] values will dictate when if we when we [2:34] have to choose between two things how we [2:36] actually make that choice and different [2:38] platforms make that choice differently [2:42] and too often I think that we look at [2:45] the different choices that a different [2:46] platform has made and we we will [2:49] criticize those choices or we will [2:51] embrace those choices but we're actually [2:53] doing is we are commenting on our own [2:56] values relative to the values perhaps of [2:59] a different system so our own values are [3:01] really important and the values that we [3:03] have shift based on what we're doing [3:06] where when we don't have necessarily one [3:09] set of values for all of the software we [3:12] write we got different software what we [3:14] write we will have different values and [3:16] we want our software to reflect those [3:19] values and I think that actually in the [3:21] in the kind of the post open source [3:22] world when we are selecting a [3:24] programming language we're looking at a [3:25] programming language we're looking at a [3:26] software platform we should be looking [3:29] as much at values as we are at anything [3:32] else do the values here reflect the [3:35] values that I want for this thing [3:36] especially when community is so [3:38] important I mean in an open source world [3:40] you're selecting community as much as [3:42] you're selecting anything else and I've [3:44] learned this the hard way where you've [3:46] got because if you like I love the [3:47] technology and the community is I've got [3:50] come comes vicious with but I really [3:51] love the technology if the community [3:53] doesn't reflect your values you will [3:54] find that the software will come to not [3:56] reflect your values as well so you [3:58] really need to need to define the right [4:00] community for the values the right [4:01] values then for it for the job the right [4:04] software for the value so what's gonna [4:05] make this a little more specific here so [4:07] this is just kind of a scattering of [4:10] random values these are this is not a [4:13] very well organized list I guess it's [4:15] alphabetical I guess I could make it [4:16] alphabetical other than that it's not [4:18] really sorted it's not meant to be [4:19] exhaustive there are lots more values [4:21] than this and each of these values kind [4:23] of mean different things to different [4:24] people so there's a lot of nuance here [4:26] but we can kind of generally agree what [4:28] it means to have performances of value [4:30] what it means to have robustness as a [4:32] value or debug ability as a value or [4:34] composability [4:35] as a value or expressiveness as of [4:38] you and you can't have it all you can't [4:42] choose all of these things we can all [4:44] agree that each of these things is [4:46] important I don't think any of us would [4:48] say that that value is just garbage and [4:51] you should never want it right I mean [4:53] for I don't know maybe there are some [4:55] things up here but I think that in [4:56] general we would say you know all of [4:58] these things are important they're good [5:00] they have their place but the real [5:01] question is when you have to make a [5:04] choice between two of them what do you [5:07] choose and those what that choice that [5:09] you make you being a software platform a [5:12] language a community that choice [5:15] reflects the core values of that that [5:20] platform or language and you can't have [5:21] every value be a core value so what are [5:24] the core values of some of these things [5:26] because these things are in tension and [5:28] I think that they do when you have these [5:30] core values they're going to attract [5:32] like-minded folks and as a result they [5:35] become self reinforcing because those [5:38] who are attracted to those values are [5:40] attracted to the software and then they [5:42] want to defend those values in the [5:44] software they want those values to [5:45] remain consistent so that they there's a [5:47] self-fulfilling prophecy here so let's [5:49] look at these values so kind of grayed [5:52] out the values that they don't have and [5:54] say you know the history of C is pretty [5:58] interesting we we tend to think of C and [6:01] UNIX as being identical twins born at [6:04] the same moment kind of in the birth [6:05] canal at the same time that's not [6:07] actually the case [6:08] UNIX was actually developed before C if [6:12] slightly units was developed originally [6:14] all in assembly and there was an opera [6:16] there was a language called B that was [6:18] kind of floating around but they didn't [6:20] really use B for very much B was slow so [6:23] B was used for some ancillary parts of [6:25] the operating system and they they saw [6:27] the need to develop a higher-level [6:30] language a structured language although [6:33] the higher level came first that would [6:35] allow them to not have to employ in the [6:37] operating system in assembly that is [6:39] that the birthplace of C is we want [6:43] effectively a better assembly we want a [6:46] non machine specific assembly and that's [6:50] what C is [6:51] see is effectively portably assemble [6:53] portable assembly the a number one goal [6:55] of C is is performance and I add [6:58] interoperability that are as well [7:00] because it is just models the Machine C [7:02] is designed to interoperate with [7:04] anything that can execute on the machine [7:06] effectively so C interoperates with [7:08] assembly it can interoperate with [7:10] effectively anything that is going to [7:12] actually operate on the machine so [7:13] interoperability is very important [7:15] portability these are important and then [7:17] simplicity one of the things that's [7:18] interesting about C is C only grew those [7:22] things that were needed to implement [7:25] UNIX so they didn't add structures to [7:28] UNIX or just C until they realize they [7:30] needed them named one UNIX so C it [7:31] really didn't have structures seems like [7:34] what do you what does he have if it [7:35] doesn't have structures seems like it [7:37] has precious precious little but [7:38] assembly doesn't have structures so why [7:40] would you and then that you know what [7:41] structures would make this a lot easier [7:42] so they added structures okay but they [7:45] kind of stopped there and C has retained [7:50] that minimalist aesthetic which i think [7:53] is very core to two C's value so this is [7:56] what I would say these values are and [7:57] it's not that C doesn't care about these [7:59] other things it's just that it [8:01] deliberately if it has to make a choice [8:02] between these or when it had to make a [8:04] choice between these these are the ones [8:06] that that it chose and admittedly C is [8:08] also in a time when a lot of these [8:10] things are much more profound tension [8:13] performance and expressiveness for [8:14] example we're very much in tension and [8:16] that they chose performance just throw [8:19] that as long as doing one letter [8:20] languages in terms of B and C might as [8:22] well throw K in there it's got nothing [8:24] to do with system software enough people [8:26] know K K and Q it's follow-on were [8:30] developed by again Arthur Whitney who is [8:33] definitely unlike a different astral [8:35] plane [8:37] so Arthur believes that the Arthur's [8:40] aesthetic is all around minimalism and [8:45] expressiveness Arthur Arthur learned APL [8:49] from Ken Iverson at age four I'm not [8:51] making this up he's like Ken Iverson's [8:53] neighbor and further Arthur has the [8:55] belief which I admire and I love and I I [8:57] mean I I don't want to like III don't [8:59] want to talk him out of this belief that [9:01] he can teach any four-year-old API [9:03] now when he told me this I had a four [9:06] year old that I knew for a fact could [9:08] not be taught APL I mean I'm Betty and [9:10] and he's like you should bring your four [9:12] year old and I will teach them aap I'm [9:14] like this is gonna end poorly for [9:15] everybody because I you are not gonna be [9:18] able to teach him APL and he's gonna be [9:20] very upset having to learn aap I think [9:22] this is not gonna do well we're not I'm [9:23] not gonna call this Bluff but I I I [9:26] admire the beauty of a brain that [9:29] believes that APL can be taught to a [9:31] four-year-old that's that's amazing to [9:34] me on but Kay's only values are in that [9:38] expressiveness Arthur wants to write a [9:40] program and I guess it's not funny I [9:42] shouldn't say without laughing in as few [9:44] characters as possible I mean that is [9:47] what beauty is - Arthur fewest number of [9:50] characters I don't know if he feels he's [9:53] gonna be vividly punished for the number [9:54] of characters uses I don't quite [9:55] understand what drives that but that's [9:57] what drives that and and he will make [9:59] code denser and denser and denser and [10:01] denser is it readable it is emphatically [10:04] not readable and it looks like you know [10:05] and from if you're of my vintage it [10:08] looks like your mom picked up the phone [10:09] when you were on the modem and you get [10:11] like a bunch of line noise like that's [10:13] like compilable K I think um but it's [10:16] beautiful [10:16] alright so that's in but these are the [10:18] only values like don't care do we dead [10:20] we don't get maintainability readability [10:21] no don't care we care about its [10:23] expressiveness in performance [10:25] that's it performs very very well and [10:27] used often for market facing kind of [10:31] operations I just gotta throw this in [10:33] there for another one that's quick [10:34] that's kind of clarifying you know [10:36] OpenBSD the operating system security [10:38] end of core values the there is no other [10:42] core value in open BSD in that and that [10:44] that's not I'm not being perative it's [10:47] actually incredibly clarifying when you [10:49] have a system that is so upfront and [10:52] transparent about this is what we care [10:54] about and we don't care if we're gonna [10:56] make the system much slower to make it [10:59] secure that's what we're gonna do if we [11:01] need to turn off hyper-threading because [11:03] we believe that hyper threading is [11:05] unsafe at any speed that's what we're [11:07] gonna go do and you're gonna lose half [11:08] your virtual cores but too bad they were [11:10] never secure they were always vulnerable [11:11] to side channel attacks but it's all [11:13] true actually that's all that that's a [11:15] totally reasonable [11:16] if [11:17] position an admirable position this is [11:19] what OpenBSD cares about and and more [11:22] power to them um I just I love auch [11:24] gotta lock in there just give you kind [11:26] of some different examples auch is [11:29] really about like writing programs [11:31] quickly I write I mean I don't know [11:33] about you but I you know I write awk on [11:35] a daily basis I write three or four [11:37] Ockham's day like I just and these are [11:40] one-liners right these are super quick [11:41] programs but awk is really beautiful in [11:45] that then I can write something super [11:46] quickly it's very simple it's pretty [11:48] expressive as these things go you can do [11:50] a lot with a little anak it's very [11:52] approachable you can get anyone to be if [11:54] you've read the awk programming language [11:56] so awk named because of aho Weinberger [11:59] and Kernighan the three people that [12:00] invented it the ark programming language [12:02] I think is an absolute model of [12:05] programming language documentation so [12:07] you you get the awk program language [12:09] it's like 130 pages the book it's [12:11] beautifully written beautifully typeset [12:13] you'll read it in like two hours and [12:15] then you're done like that's it [12:17] you know all about there's there's [12:19] nothing more to know about Ock like you [12:21] actually learned it all the end and it's [12:24] there's something that is great and [12:26] beautiful by that it's simple its [12:27] approachable and so on I think you might [12:29] be able to teach a four-year-old awk [12:30] maybe you know that's crazy you can't do [12:32] that I died but maybe a seven-year-old [12:34] I'm okay now I have never written a line [12:37] of Scala so and if you like if you like [12:39] rush the stage because this is wrong um [12:41] I'm sorry that's I put a question mark [12:43] there to try to reason with the mob as [12:46] they were throwing chairs at me so and I [12:50] I'm not necessary asserting this but it [12:52] is just kind of like try this one I [12:53] think it's a useful exercise to think [12:55] about like what are the core values for [12:57] the things that I implement in the [12:58] things that are important to me because [13:00] that's probably why they're important to [13:01] you that's probably why you gravitated [13:03] them at some level um in what I see in [13:05] Scala is certainly expressiveness [13:07] writing is very important I think you've [13:10] got to put interoperability way way way [13:12] up there I mean the whole point of Scala [13:14] is to be able to interact with the Java [13:16] ecosystem at large that's a very core [13:18] principle to me that's a core value I [13:19] mean I remember actually seeing what I [13:21] think must have been one of Martin's [13:22] very first talks on Scala um back and I [13:25] think 2004 and the this was a big deal [13:29] the ability to reuse [13:31] java classes in a language that provided [13:34] integrity and robustness and [13:36] expressiveness and composability [13:37] and I'm not saying that Scala doesn't [13:39] care about the things that that aren't [13:41] bolded here but just if it has to choose [13:43] this is what scholars gonna choose I [13:45] thought was very interesting because you [13:46] saw the panel last night where Martin [13:48] was being asked what is your kind of [13:49] vision for Scala going forward and it [13:51] wants to make it easier to write robust [13:54] programs it's really about writing [13:55] robust software and I thought it was [13:58] interesting too that eliminating some of [13:59] the things like the XML in URLs I did [14:03] not know that XML literals but [14:04] eliminating some of things that we no [14:06] longer need because they're not gonna [14:07] serve these values I'm not sure where [14:09] xml literals fall on the values and the [14:13] moon Ranelagh okay so the there the [14:17] challenge for that we have in system [14:19] software that is not necessarily a [14:21] challenge that you might have in [14:22] software your writing but in the in in [14:23] the software in the system software that [14:26] is beneath you or beneath us that is [14:28] that that is that is say it comprises [14:31] the the foundation upon which we build [14:33] the values are dictated by those who [14:36] will use the software it's dictated by [14:38] the expectations like the the an [14:40] operating system that for example does [14:43] not hold of the values around say [14:45] robustness or safety or or security that [14:50] operating system is one that is not long [14:52] for this universe because you're not [14:53] gonna want to use it no one wants to [14:55] have an operating system that panics on [14:57] them no one wants have an operating [14:58] system and our expectations for the [15:00] operon system and for system software [15:01] are very very very high and rightfully [15:04] so they should be high on and so in an [15:07] in particular if there are certain [15:08] values that if your system software [15:09] doesn't have it your software can't have [15:12] it and we are learning this the hard way [15:14] because these values go even deeper into [15:16] security right I mean 2018 has been my [15:19] Anna's horrible us because of and it was [15:22] it was on you know January 2nd of 2018 [15:25] when I'm looking at this hacker news [15:27] story that someone trying to kind of [15:29] reverse engineer some patches that are [15:30] being floated against the Linux kernel [15:32] thinking there may be a really serious [15:33] security vulnerability here with Intel [15:36] and the US and that was the beginning of [15:38] the end for my 2018 because 2018 has [15:41] taught us that that security what was [15:45] ultimately subservient to performance in [15:47] the design of the microprocessor and we [15:49] were all complicit in that by the way [15:50] like what's not it's easy to kind of [15:52] like blame Intel for that but the [15:54] reality was we were all complicit in [15:56] that we that's what we demanded the [15:58] problem is we discovered that that that [16:00] very lowest substrate because it chose [16:04] performance over security at some very [16:07] key and implicit junctures we ended up [16:09] with a substrate that self above it in [16:11] the operating system the system software [16:13] that now lost security as a value it [16:16] doesn't matter how much how dear you [16:19] hold security if you have [16:22] hyper-threading enabled doesn't matter [16:24] because because the hyper threading [16:27] itself is not secure or it doesn't [16:30] matter in if you don't have kernel page [16:32] table isolation doesn't matter how dear [16:34] you hold it because now you are [16:35] vulnerable to an attack but from a [16:38] substrate that ultimately chose [16:40] something else over over security and [16:42] this is very painful for us it's very [16:44] painful when you're when the the [16:47] infrastructure the layer that you depend [16:48] on because we all depend on layers [16:50] beneath us when the layer that kind of a [16:52] jack-in-the-box hey surprise I don't [16:54] hold the values you thought I held it's [16:56] like okay well I guess I will cancel [16:58] what I was gonna do for 2018 and spend [17:00] the time getting the system back to [17:03] where I thought it was on on December [17:05] 31st 2017 which is what we have [17:08] effectively done it's been it's been [17:09] very frustrating in that regard but [17:11] that's a four system software we have to [17:14] hold these values it is essential so [17:17] these are the values that we demand of [17:19] system software um it's got to be [17:22] compatible right you you're not gonna an [17:24] upgrade to a microprocessor to an [17:26] operating system to a database when that [17:28] breaks your software that's not okay [17:30] it's got to be developed we have to [17:31] understand what's going on why things [17:32] are failing you've got to have integrity [17:34] as a core value you can't have data [17:35] corruption um you need performance I [17:38] really wish we get just like can we just [17:39] get rid of performance then it'll be [17:41] fine and we don't need performance you [17:43] know a the the late great Roger Faulkner [17:45] I worked with at Sun Microsystems for a [17:46] long time which said that performance is [17:48] the root of all evil and and he's right [17:51] performance is the root of all evil if [17:52] we are are happy with our systems not [17:55] performing well things get a lot easier [17:57] but if [17:58] that's not we don't want to do that [17:59] right performance is important [18:01] performance drives right to the [18:03] economics of what we're doing it's not [18:04] okay to be wasting cycles that we don't [18:07] need to waste we actually have to have [18:09] performance as a constraint and this can [18:11] be brutal by the way especially when the [18:13] numbers are small it's like man this [18:14] thing is like 2% faster than you guys [18:16] just like that 2% is brutal to get out [18:19] of but it's important it should be [18:21] important it's important that we hold [18:22] that value for our system software it's [18:24] got to be resilient it's got to be [18:25] robust it's got to be safe it's got to [18:27] be secure we that that's paramount that [18:30] it's secure [18:30] it's be stable it's gonna be thorough in [18:33] that our system software our [18:34] microprocessors our operating systems [18:37] even our databases we need them to [18:39] support a wide range of things they [18:41] these are not purpose-built things we [18:43] can't afford for them to be [18:44] purpose-built things they have to be [18:45] generic that generic ism requires a [18:48] thoroughness that is actually really [18:49] challenging we got to be transparent we [18:51] got any kind of the day of proprietary [18:53] glop well it was but it behind us and [18:55] then that's actually this is coming back [18:57] actually with the whole cloud thing so [18:59] I'm we work for a cloud cloud provider [19:01] although our software's all open-source [19:02] but right now us compute is being [19:04] reprioritized by the by the cloud [19:06] providers so transparency may be fading [19:09] as a value I hope that we'd go and [19:10] demand that it back again okay so I just [19:12] wanna remind you with the platform that [19:14] the core values of C are so we're just [19:16] gonna kinda do this all right so that's [19:18] what we demand that's C what we demand C [19:21] it's like right eye left eye right eye [19:23] left eye right eye left eye all right [19:27] there's only one value these things have [19:29] in common performance that's it [19:33] everything else and this is actually and [19:36] you know what Roger accepted Roger [19:38] passed away a couple years ago Roger you [19:40] are haunting us from the grave because [19:41] you are actually all right Ron [19:42] performance actually is the root of all [19:43] evil here because if it performance [19:48] ultimately in terms of the values we [19:50] demand for system software we do demand [19:51] performance over all else that is the [19:53] reality we might not like that but we [19:55] cannot accept a system that is better in [19:58] all of these other attributes but [20:00] suffers in terms of performance and for [20:03] evidence of that just look at history's [20:05] graveyard of systems that did deliver [20:08] and you will find people that that talk [20:10] about you know capability based systems [20:12] or micro no based systems or other other [20:14] systems that ultimately fell down on [20:17] this most important criteria and I say [20:19] how you sort fork UNIX so I love my [20:20] kernel so I'm not I'm not trying to pick [20:22] I pick at wounds but performance [20:26] ultimately is is the most important [20:27] thing so that's C C is clearly I mean we [20:30] kind of got in there with C but it's [20:31] been really painful [20:32] well what about C++ all right well this [20:34] might be for C++ so so C++ okay [20:38] so we're definitely gonna get rid of [20:40] simplicity I don't have a way of saying [20:42] there should be a way of like I need a [20:43] strikeout to be like I hate simplicity [20:46] like that's like I am actually anti [20:48] simplicity cross that one out [20:49] so see West boss is like anti simplicity [20:51] um and then I also decided that again in [20:55] my kind of as long as I am issuing [20:58] fatwas against programming languages I I [21:01] decided that expressiveness is important [21:04] interoperability is actually less [21:06] important to C++ C++ has actually made [21:09] choices yes C++ is a better C and yes I [21:14] think it can still compile C although [21:16] that becomes less and less important [21:17] over time but the C++ struggles with [21:20] interoperability at a deeper level where [21:22] you have components that are written in [21:23] non C++ trying to cooperate with [21:25] components that are written in C++ it is [21:28] possible but very very painful and C++ [21:31] does not make it easy [21:32] across the board I mean it starts with [21:35] name mangling and gets much much worse [21:36] it's really really painful to make [21:38] software uh you have to design your C++ [21:41] to explicitly interoperate with C which [21:43] is very frustrating because you have [21:44] these software out there that it's [21:46] actually only in C++ is gonna be very [21:47] hard to actually get a dinner operate [21:48] with C so this gives us the this this [21:52] tremendous divide this tremendous [21:53] disconnect between the values that that [21:57] the system software programming [21:59] languages have had in a way performance [22:00] and then nothing else um and the values [22:04] that we need for the software we have [22:05] have all these other values now we've [22:07] gotten there um it's been a long painful [22:11] arduous path the reality is our system [22:15] software does work it is actually it [22:17] does have all these other values it does [22:20] it is stable it is sick it is I mean it [22:22] is relatively stable it is relatively [22:25] secure [22:26] or I thought it was secured on on [22:27] December 31st 2017 anyway it is [22:30] relatively safe relatively robust does [22:32] perform well but we've gotten there the [22:35] painful way it has taken us a very long [22:38] time we've written a lot of bespoke [22:41] tooling now we've also gotten very good [22:43] at it I'm good at writing my C does not [22:47] it is not going to dereference memory it [22:49] does not have that is not a failure mode [22:51] that I have in the C that I write [22:53] because I've been doing this for a long [22:55] time and I know how to malloc and free [22:56] and I know how to create dynamic data [22:58] structures and do that do so completely [23:00] safely and I can very quickly that's [23:02] good [23:03] it was very painful and the truth is it [23:06] is very much dependent on me the [23:08] programmer and my reviewers and my [23:10] testing and so on there's no net that is [23:13] provided by the language at all the [23:15] language is allowing me to do whatever I [23:17] want it's you know it's like a [23:19] Montessori Preschool as long as we all [23:20] worship at the old or at the altar of [23:22] performance um so the you know the [23:27] question is like it can we do better [23:28] because we've succeeded despite the [23:30] language not because of it is there an [23:32] opportunity to better and I was actually [23:33] at the point where I was beginning to [23:36] despair a little bit where I had and yes [23:40] there are the language to come out you [23:42] may be familiar with giant because of [23:44] nodejs I had this like great belief that [23:48] no js' was going to be what would save [23:50] us all um yeah and if you would be like [23:53] no that's just JavaScript I'm like I [23:54] know I know it's just Josh but I wanted [23:56] so much better I wanted so much better [23:58] for JavaScript it wasn't gonna be [24:00] JavaScript it was gonna be a dynamic [24:01] language in which we could write robust [24:03] server-side software and it's just [24:05] JavaScript it's just JavaScript dude I [24:07] it is just JavaScript and and what I [24:09] mean by that is the values that [24:11] JavaScript has aren't bad values but [24:14] they are not the values that we have for [24:15] system software that defies JavaScript [24:17] as is really around velocity and [24:20] especially approachability we want as [24:21] many people as possible to be able to [24:23] write JavaScript and that is not that's [24:25] I think that's a great ambition and [24:26] there's nothing wrong with that value it [24:28] is antithetical to system software [24:30] because that does become in tension and [24:33] suck if we want to choose an abstraction [24:34] that allows ten thousand more people to [24:38] write software but [24:39] that soft word will be rife with edge [24:41] conditions that they will probably never [24:42] encounter should we do it if your first [24:45] value is robustus you say no of course [24:47] not [24:47] if your first value is approachability [24:49] and and growth then yes of course you [24:52] should and that is the fundamental [24:53] tension for us um so I want us to do [24:56] better um I I was I was beginning to [24:59] despair because I didn't see a language [25:01] that was that was really offering [25:02] fundamentally different values and then [25:05] along came rust and now along came rust [25:08] rust has been around for a long time [25:10] started actually a long long long time [25:12] ago started in like 2006 or just a [25:16] little bit later but rust has kind of [25:18] has grown over time and I like I think [25:21] many people have been increasingly rust [25:23] curious over the years right and my my [25:26] rust curiosity has has grown over the [25:30] years because rust has this incredibly [25:32] interesting system of ownership where [25:35] whereby you are the programmer are going [25:39] to work with the compiler to figure out [25:42] who owns what when who owns what piece [25:45] of memory the compiler is gonna restrict [25:48] what you do and you're not going to [25:50] burst into tears when it does it that's [25:51] like that that's the bargain that you're [25:53] gonna have with the compiler as a result [25:55] the compiler knows when things need to [25:58] be allocated and when things need to be [26:00] de-allocated when they're that are still [26:02] reference to this and when there is no [26:04] longer reference to and you're gonna [26:05] work with it and as a result you get the [26:08] denied then the dynamicism that you get [26:10] in a garbage collected language but the [26:13] performance of explicit memory [26:14] management and this is amazing and [26:16] importantly unlike see rust is highly [26:20] composable so the big problem with see I [26:22] mean this is always the problem right [26:23] it's not it's not you it's the other [26:26] person like I know how to write memory [26:28] say I know how to actually deal with [26:29] memory safely but calling you to a [26:31] library that jerk no I don't know how to [26:33] do a memory safely or but it's even [26:35] worse than that right [26:36] because what where things get dropped is [26:38] in the boundary is in the the library is [26:40] allocating something on your behalf that [26:42] you are explicitly or implicitly [26:43] expected to free or deallocate you lose [26:45] track of that you've got a memory leak [26:47] memory corruption are worse it is very [26:49] hard even if you're very good at seeing [26:52] a between here [26:52] career it's very hard to compose it so [26:55] what we end up doing is having these [26:57] very minimal kind of structures where we [26:59] embed these things in larger structures [27:01] and we're able to do so totally safely [27:03] but ultimately sub-optimally rust [27:06] actually allows us to have higher [27:07] performing primitives and so as a result [27:10] and I'll come back to the rust values [27:12] but in in my experience and this is my [27:14] experience I'm not trying to draw a [27:16] large conclusions this is a bit of [27:18] software that is what I was alluding to [27:19] us on in the panel that I'd written in C [27:21] and I'd kind of written in you know hand [27:24] optimized C I went to rewrite it and [27:26] rust because I was increasingly rust [27:28] curious and wanted to finally say that [27:30] rust curiosity by writing some real rust [27:32] after a lot of back and forth of the [27:34] compiler some tears that I wiped away um [27:36] do it like let the wookie win is my [27:39] advice when you're dealing with rust [27:40] that what you want to rust wants you to [27:43] do things certain ways and you're much [27:45] better off doing things the way rust [27:47] wants you to do it so I did it in a way [27:48] that was obviously suboptimal but fine I [27:50] can get it to compile I just gotta like [27:52] I don't even care about performance [27:53] anymore just let me get this thing [27:54] working and then and I know it's gonna [27:57] perform terribly and then I ran it and [27:59] it outperformed my C it's like what how [28:02] did that happen how and I took it apart [28:05] and how did I outperform I see well this [28:07] particular software spends all of its [28:08] time rebalancing a binary tree and in [28:11] rust the primitive that I was using was [28:13] an AVL tree which is the thing we've [28:15] used for ever and I've got a very robust [28:16] AVL tree implementation that I've used [28:17] in rust you don't have to AVL tree [28:19] actually the betray B tree you may [28:21] remember from databases right but the [28:23] rust observation is actually with the [28:25] memory hierarchy being what it is a [28:26] beech tree actually makes sense just in [28:28] software that's not talking to disk you [28:30] can view DRAM as the disk that you're [28:32] talking to and a beech tree actually [28:33] makes a lot more sense beech trees a [28:35] pain in the butt to implement but with [28:36] rust you can just use it you don't have [28:38] to actually know any of the [28:40] implementation details of it and as a [28:42] result it outperformed my safe in large [28:45] part because the data structure but also [28:47] because there are optimizations that [28:48] Russ can make that C could not make and [28:50] then of course it was like wow that's a [28:52] GCC issue how about clang I'm like clang [28:53] is not gonna fundamentally change the [28:55] physics of my C which it doesn't like [28:57] clang makes it a little bit better this [28:58] is the lower is better here um so this [29:01] was really interesting to me and it [29:03] shows the the kind of the core values of [29:05] Russ [29:06] um so yes performance it has to be [29:09] performance it kind of the epicenter of [29:10] the universe but you get that [29:11] composability the expressiveness that [29:13] you in the scala world have had for a [29:15] long time we now get this to have this [29:18] at a much lower level we get safety we [29:20] get security we get rigor we get [29:21] robustness we get integrity and very [29:24] importantly we get interoperability and [29:26] this is actually the difference between [29:27] rust and other languages that look [29:28] somewhat similar is rusts emphasis on [29:31] interoperability rust does not aspire to [29:34] rewrite everything in rust rust is [29:35] trying to cooperate with those systems [29:37] that already exist so it's not just [29:39] ownership um the I know that you know [29:43] and you would be right to be annoyed [29:45] when a bunch of systems people discover [29:47] algebraic types like it's a brand new [29:49] invention it's like hey I just found out [29:52] like I'm getting clean water out of the [29:54] tap I don't have to boy you're just like [29:56] yes you knucklehead like yes you clean [29:59] water it's valuable like your babies are [30:01] no longer dying it's amazing um but [30:03] algebraic types okay and I knew about [30:05] algebraic types in the abstract but to [30:07] actually be able to see how algebraic [30:09] types can be used for really concise [30:11] error handling you can make much more [30:13] robust stuff and again you know this I'm [30:14] actually I'm literally preaching to the [30:15] choir so what next [30:16] um but algebraic types are amazing and [30:18] they are amazing for reasons beyond what [30:20] I appreciated um [30:21] hygienic macros true story I did not [30:24] know how to spell hygienic before rust [30:26] hygienic is kind of a pain in the butt [30:28] you got that second eye in there like [30:29] what's that doing there [30:30] but the the eye I have been so far from [30:33] hygienic macros that I literally didn't [30:35] know how to spell it [30:35] now macros are a key for us and C we use [30:39] the C preprocessor all the time I could [30:41] not have written the code that I've [30:42] written in my career without C [30:43] preprocessor macros are very important [30:44] the macros and rust are amazing the [30:46] foreign function interface is what [30:47] allows it to interact with C based [30:48] systems it's outstanding and then [30:50] there's this unsafe keyword which is [30:52] this kind of get-out-of-jail kind of [30:54] like a furlough program you get to go [30:57] away a conjugal visit with your memory [30:59] you don't actually um sometimes these [31:03] metaphors occur to me on the fly and I [31:04] realize like as it's going out of my [31:06] mouth the other part of my brain is like [31:07] no let's kind of let's pull that one [31:08] back please pull them out here that [31:09] one's gone all right fine never mind [31:11] it's been it's been tweeted forget it um [31:12] but the the unsafe keyword allows you to [31:16] relax certain restrictions that Russ [31:19] puts in place [31:20] that allows you to then in very isolated [31:22] parts actually leverage what you know of [31:25] memory and to build even higher [31:27] performing things better things but [31:28] you've really can find that unsafety so [31:30] I think actually unsafe keyword is [31:31] terrific terrific community thriving [31:34] ecosystem I mean there's a lot to love [31:35] about it um so that's the promise of [31:37] rust there there is uh it and I made [31:41] made references last night but the [31:43] beauty of rust is that it shifts the [31:44] cognitive load back from software when [31:47] it's running in production to the [31:48] developer and development which is great [31:50] news if you're me I think great is if [31:53] you're us but it means if you're the [31:55] developer and development you're like [31:56] where did all this cognitive load come [31:58] from like I I'm much more used to being [32:00] able to just kind of like push it into [32:01] production but I know there's a lot more [32:03] cognitive load a lot more things you [32:04] need to think about and Russ complains [32:06] about things that seem very very very [32:09] pedantic and it can take a while to [32:12] realize that oh rest is right actually [32:14] rust is right there's an actual real [32:15] issue here I mean there are a couple [32:17] instances where people are convinced [32:19] they're having a fruitless argument with [32:20] a compiler because the compiler is wrong [32:22] and they realize the compiler is [32:23] actually right so um it's a really [32:25] interesting that regarding it restricts [32:26] what we can do it can be very very [32:28] frustrating this is a quote from from [32:30] the programming rossbach which I love [32:32] that they you have a period of intense [32:34] arguing with a compiler at the end of [32:36] which the code looks rather nice as if [32:38] it'd been a breeze to write and runs [32:40] beautifully but there's no way that code [32:42] is like you don't get the screams of [32:44] pain that the developer had in getting [32:46] that that kind of beautiful code that [32:47] beautiful artifact so the the the peril [32:50] of rust um is that it's got less of an [32:52] advantage I think when we are [32:54] reimplemented extant systems so when the [32:57] software already works it's less clear [32:59] to me especially you've got multiple own [33:00] data structures like an OS kernel um I [33:02] think that's gonna be brutal for rust [33:04] but there are a lot of opportunities for [33:05] us and start to kind of speed through [33:06] here at the end but there are a lot of [33:08] opportunities for rust because of its [33:10] interoperability as a core value god [33:12] bless that interoperability and [33:14] performance is a core value because it [33:16] allows us to do with rust what we did [33:19] with C which is take an iterative [33:21] approach start rewriting things in rust [33:24] we don't have to rewrite the entire [33:26] world in rust we can start rewriting [33:28] parts of Ross and I think this is [33:29] something that the scholar community [33:30] really gets from its interoperability [33:32] with Java but I think we're [33:33] really learning it in system software um [33:35] and so I think it's it's a new dawn of [33:37] development in that regard the system is [33:39] obviously much they're much broader than [33:41] just the operating system there are a [33:42] lot of use global components that are a [33:43] natural fit for rust if I were writing [33:45] system D today I mean I didn't write [33:47] system B but if one were right actually [33:49] mentioned system B if one were writing a [33:51] user level facility to manage software [33:54] as a service I would write that in rust [33:57] absolutely and in particular just to [34:00] close with the other body of software [34:01] that I really want to see rewritten is [34:03] the software that you can't see and I [34:05] can't see and none of us can see the [34:06] software that works beneath us is [34:07] firmware I've been fond of saying but I [34:10] believe it fervently that we are engaged [34:12] in a war with firmware it is humanity [34:15] versus firmware and everyone needs to [34:17] pick a side so I hope that you pick the [34:19] side of humanity and I think there's a [34:21] lot of opportunity to rewrite that Louis [34:24] all the software which I honestly is [34:26] still in assembly or C I think there's a [34:28] lot of opportunity to rewrite that in [34:30] Rus so I think the you know one of the [34:31] things that the Rus community says over [34:32] and over again is we can have nice [34:35] things and I think that that is very [34:37] much borne out by Rus values the values [34:40] themselves are a great fit for system [34:42] software it doesn't mean it's a fit for [34:43] everything and you shouldn't let anyone [34:45] try to convince you that it's a fit for [34:47] everything it's not but for certain [34:49] bodies of software and in particular the [34:51] software that I like to write it's a [34:53] great fit and really liberating and I [34:55] think we're gonna see a lot of system [34:57] software written in rust with that thank [34:58] you very much [35:07] yeah I don't like negative five minutes [35:09] for questions okay yeah I'm happy to [35:13] take a question or two yes yeah so [35:21] that's a great question and I mean [35:23] clearly like if when you're talking to [35:25] si si you can clearly be zero your [35:27] address space I mean so it's Russ is [35:30] going Russ is going to help you out with [35:32] the safety of your code but when you [35:34] need it I mean so for example if you [35:36] want to call em map the which is allows [35:39] you to actually M map a an object into [35:41] your own address space that's an unsafe [35:42] operation so you will need to wrap that [35:44] in on safety I think what it's doing is [35:46] confining that on safety such that [35:49] you're aware of it so it does help you [35:50] out in that it limits it as opposed to [35:52] like letting that poison an entire [35:54] application that make sense yeah cool [35:57] any other other questions [36:00] yes so what do you think of the idea of [36:04] what systems for every but there's other [36:06] spaces where it's very important to just [36:09] in yes we're worse they did what was [36:13] intended right you see a role for us not [36:17] just as a system software but for [36:19] example like cooperating what they did [36:23] game or as some kind of date libraries [36:25] and where you can combine the two system [36:29] absolutely [36:31] and I'd say any place where these values [36:33] are important Russ is gonna have a place [36:35] and in particular where these are the [36:38] choices you want to make and in [36:40] particular particular where performance [36:42] is the is your top choice if if [36:43] performance is your overarching value [36:45] I think rust is absolutely gonna have a [36:47] place all right I think I'm out of time [36:49] thank you very much everybody [36:51] [Applause] [37:01] you