Some Were Meant for C：一门难以驾驭的语言的持久性

导读

这篇论文探讨 C 语言为何长期难以被取代。作者提出两个核心观点：一是 C 的流行源于“内存地址”这一便于检查和修改的心智模型，而非单纯的运行时性能；二是无需修改 C 语言标准，通过新的编译器实现即可加入类似托管语言的运行时安全检查——例如数组越界检查只是实现惯例而非语言规范要求。

HN 关注点：HN 读者围绕“C 成功的真正原因”和“更安全的 C 实现是否可行”展开激烈争论，涉及 Rust 等安全语言的替代路线之争。

关键词　C语言系统编程内存安全Rust

HN 评论精选

这几条评论里：质疑 1　补充 3

补充总结论文两大论点：C 的心智模型优势 + 不改标准即可实现更安全的 C 编译器

这篇论文有两个主要论点：1) C 的流行更多是因为内存地址作为检查和修改的概念模型在认知上很轻松，这个心智模型的重要性超过运行时性能；2) 没必要切换到 Java/C#/Rust 这类“安全”语言——在不改变 C 规范的前提下，新的编译器实现就能加入类似托管语言的运行时安全检查。论文举例：C 从未定义数组访问不做检查，这只是实现惯例而非语言事实。这两个观点看似正交，但作者最后将它们联系在一起。打个比方：如果说“足够聪明的编译器”声称 Python/Ruby 理论上能编译得像 C 一样快，那作者走的是相反方向——一个“足够聪明的运行时”可以让新的 C 编译器实现做各种额外检查和簿记，而不需要改动任何 C 源码、不违反现有 C 标准。

jasode查看英文原文

This is a long paper and the author has 2 main claims: 1) C Language popularity is more to do with cognitive ease of memory addresses as a conceptual model for inspection and change. Author claims memory address mental model overshadows runtime performance. 2) switching to "safe" languages like Java/C#/Rust is not necessary. With no changes/violations to existing C Language specification, a new/different implementation (compiler) can add more runtime safety checks similar to managed languages. An example from the paper: >Consider unchecked array accesses. Nowhere does C define that array accesses are unchecked. It just happens that implementations don’t check them. This is an implementation norm, not a fact of the language. Those 2 ideas look orthogonal but he ties them together at the end. I'll take some poetic license (e.g. a little exaggeration) to reword the author's idea to help spur discussion... Consider the idea of the Sufficiently Smart Compiler[1] that claims that a "slow" and "high-level" language like Python/Ruby could be theoretically analyzed and compiled to be as fast as C or handcrafted assembly. In a way, the author is coming from the opposite direction. If you had a "Sufficiently Smart Runtime" for a new C Language compiler implementation, it could (theoretically) do all sorts of extra checks and bookkeeping that wouldn't require any changes to C source code and wouldn't violate the existing C Language standard. (E.g. Imagine a new C runtime that did many checks similar to Valgrind + UBSAN + ASAN + debugger memory fences, etc.) Would the program execution be slower? Well yes, but that's not really an issue because according to author's claim #1, what programmers really like about C is the mental ease of accessing memory addresses. The performance is important, but it's a secondary benefit -- according to the author. [1] http://wiki.c2.com/?SufficientlySmartCompiler

质疑质疑论文：C 成功只因 Unix 的历史运气，更安全的 C 实现注定重蹈覆辙

这是又一篇过度分析 C 成功原因的文章，其实原因很简单：1973 年 Unix 免费且运气好地占了有利位置，Unix 流行起来，C 是 Unix 的语言，所以 C 流行了。C 并没有什么修改版 Pascal 或 Algol 不具备的内在优势。这类文章还总是忽略一个事实：过去十年左右 C 和 C++ 的流行度在下降，新程序员不再像 90 年代那样学 C，而是从 JavaScript、Python、Ruby 甚至 PHP 入手。我对“我们需要一个新的更安全的 C 实现”这一结论也高度怀疑：换编译器对很多项目是很高的门槛，而且最终还是带着 C 的所有老问题——头文件、没有命名空间、糟糕的标准库等等。相比之下，换新语言（实践中通常是渐进式地用新语言写新组件）门槛同样高，但收益更大。这就是为什么更安全的 C 版本多年来反复失败。

pcwalton查看英文原文

This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fact that in the past decade or so, C and C++ have been declining in popularity. By and large, new programmers are not learning C the way they were in the '90s. For better or worse (personally, I think, for the better), they're starting with JavaScript, Python, Ruby, or even PHP. I'm highly skeptical of the conclusion that what we need is a new safer implementation of C, too. Switching to a new compiler is a very high burden for a lot of projects, and at the end of the day they're still left with all the problems of C, like header files, no namespaces, terrible standard library, etc. etc. (Even adding compiler switches is a high burden, which is why Linux distros took so long to widely deploy basic things like -fstack-protector.) By contrast, switching to a new language (or incrementally writing new components in a new language, which is how this always goes in practice) is also a very high burden, but the benefits are larger: you don't have to deal with all the problems of C. In my view, this is why safer versions of C have repeatedly failed over the years, while new languages have flourished. Migration to a new language or a new compiler is expensive no matter what, so teams will only do it if they see enough benefit to justify the expense of doing so. Merely adding some amount of safety to C isn't worth it, but the large safety and productivity gains you can get from a different language can be.

补充安全 C 实现用于系统编程的关键缺口：缺乏跨语言的二进制数据布局描述标准

这样的安全 C 实现真的适合系统编程，而不只是应用编程吗？如果我内存映射一个文件，只有当其结构和含义（大致即边界和类型）能像其他内存对象一样被描述时，我才能安全地访问它。目前缺乏提供这类描述的工具和系统——但这是近年运行时类型信息工作的合理延伸。关键在于：目前有一些描述任意二进制数据布局的零散系统——C 结构体/联合体、Erlang 二进制模式、ASN.1、Kaitai Struct——但没有任何一个真正跨语言流行起来。从其他语言调用 C API 时很难不感受到这种数据格式壁垒。如果我们想要真正的多语言系统（而不是一堆别扭的 C FFI），就必须解决这个壁垒。

panic查看英文原文

Is such a safe implementation of C really suitable for systems programming, rather than merely application programming? If we understand system-building as communicativity, then certainly such a system retains communicativity—so long as alien objects can be described to it in a manner sufficient for dispatching the same dynamic checks. If I memory-map a file, say, I can safely access that memory only if the structure and meaning—the bounds and the types, roughly—are described much like those of other in-memory objects. Tools and systems for providing these descriptions are currently lacking—but are a logical extension of the runtime type information already developed in recent work. In the case of file formats, some cases like the ELF example we saw earlier (§5.5) show that the format has already been defined for us, thanks to the manifest layout of objects declared in C. This is a key point. There are scattered systems for describing the layout of arbitrary binary data—C structs/unions, Erlang binary patterns, ASN.1 Encoding Control Notation, Kaitai Struct[1]—but nothing has really caught on across language boundaries. It's hard not to feel this data format barrier when you're using a C API from another language. We'll need to do something about this barrier if we want a true multi-language system (not just a bunch of awkward C FFIs). [1] http://kaitai.io/

补充引用 Duffy 演讲强调兼容性对采用的关键作用，并预测 Rust 难以取代 C

相关推荐：Joe Duffy 在 RustConf 2017 的演讲《Safe Systems Software and the Future of Computing》。其中一个要点是与现有系统的兼容性对采用至关重要（他们整个项目被取消、几乎全部推倒重来，是惨痛教训）。他主张逐单元重写而非大爆炸式重写，和 Kell 在本文中的主张一样。Windows 上与 C 的兼容应该比 Unix 世界更容易，因为整个 OS 是围绕二进制协议 COM 架构的。我的感觉是 Rust 早期对兼容性考虑不够，直到遇到采用问题才开始重视。另外 Rust 更多是在和 C++ 竞争，而它几乎没有尝试与 C++ 兼容。个人认为 Rust 不会成功取代 C：会有一定采用量，但 Linux 内核十年后仍会以 C 运行在无数设备上；二十年后会有别的东西取代 C 或 Linux，但那不会是 Rust。

chubot查看英文原文

Related: "Safe Systems Software and the Future of Computing by Joe Duffy" at RustConf 2017. https://www.youtube.com/watch?v=CuD7SCqHB7k I summarized this excellent talk here [1], but one of the main points is that compatibility with existing systems is important for adoption. (They learned that the hard way -- by having their entire project cancelled and almost everything thrown out.) He advocates unit-by-unit rewrites rather than big-bang rewrites, just like Kell does in this conference article. And compatibility with C in Windows should be easier than it is in the Unix world, because the whole OS is architected around a binary protocol AFAIK -- COM. My sense is that Rust may not have thought enough about compatibility early in its life. Only later when they ran into adoption problems did they start talking more about compatibility. Also, it seems Rust competes more with C++ than C, and there seems to be very little attempt to be compatible with C++ (although perhaps that problem is intractable.) Personally I don't think Rust will be a successful C replacement. It will have some adoption, but the Linux kernel will still be running on bajillions of devices 10 years from now, written in C. And in 20 years, something else will come along to replace either C or Linux, but that thing won't involve Rust. [1] https://www.reddit.com/r/ProgrammingLanguages/comments/6y6gx4/safe_systems_software_and_the_future_of_computing/

历次讨论

2017Hacker News 讨论帖165 分 · 240 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

Some Were Meant for C：一门难以驾驭的语言的持久性

导读

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木