35年老程序员个人谈：C语言时代行将落幕

　　这几天来，我（EricRaymond）在思考那些正在挑战C语言的系统编程语言领袖地位的新潮语言，尤其是Go和Rust。思考的过程中，我意识到了一个让我震惊的事实我有着35年的C语言经验。每周我都要写很多C代码，但是我已经记不清楚上一次我创建一个新的C语言项目是在什么时候了。
　　如果你完全不认为这种情况令人震惊，那你很可能不是一个系统程序员。我知道有很多程序员使用更高级的语言工作。但是我把大部分时间都花在了深入打磨像NTPsec、GPSD以及giflib这些东西上。熟练使用C语言在这几十年里一直就是我的专长。
　　但是，现在我不仅是不再使用C语言写新的项目，甚至我都记不清我是什么时候开始这样做的了，而且回头想想，我觉得这都不是本世纪发生的事情。
　　这个对于我来说是件大事，因为如果你问我，我的五个最核心软件开发技能是什么，“C语言专家”一定是你最有可能听到的之一。这也激起了我的思考。
　　C语言的未来会怎样？C语言是否正像当年的COBOL语言一样，在辉煌之后，走向落幕？
　　我恰好是在C语言迅猛发展，并把汇编语言以及其它许多编译型语言挤出主流存在的前几年开始编程的。
　　那场过渡大约是在1982到1985年之间。在那之前，有很多编译型语言争相吸引程序员的注意力，那些语言中还没有明确的领导者；但是在那之后，小众的语言就直接毫无声息的退出了舞台。
　　主流的语言（FORTRAN、Pascal、COBOL）则要么只限于老代码，要么就是固守单一领域，再就是在C语言的边缘领域顶着愈来愈大的压力苟延残喘。
　　而在那以后，这种情形持续了近30年。尽管在应用程序开发上出现了新的动向：Java、Perl、Python，以及许许多多不是很成功的竞争者。起初我很少关注这些语言，这很大一部分是因为在它们的运行时的开销对于当时的实际硬件来说太大。因此，这就使得C的成功无可撼动。
　　为了使用和对接大量已有的C语言代码，你得使用C语言写新代码（一部分脚本语言尝试过打破这种壁垒，但是只有Python有可能取得成功）。
　　回想起来，我在1997年使用脚本语言写应用时本应该注意到这些语言的更重要的意义的。当时我写的是一个名为SunSITE的帮助图书管理员做源码分发的辅助软件，当时使用的是Perl语言。
　　这个应用完全是用来处理文本输入的，而且只需要能够应对人类的反应速度即可（大概0。1秒），因此使用C或者别的没有动态内存分配以及字符串类型的语言来写就会显得很傻。
　　但是在当时，我仅仅是把其视为一个试验，而完全没有想到我几乎再也不会在一个新项目的第一个文件里敲下intmain（intargc，charargv）这样的C语言代码了。
　　我说“几乎”，主要是因为1999年的SNG。我想那是我最后一个用C从头开始写的项目了。
　　在那之后我写的所有的C代码都是在为那些上世纪已经存在的老项目添砖加瓦，或者是在维护诸如GPSD以及NTPsec一类的项目。
　　当年我本不应该使用C语言写SNG的。因为在那个年代，摩尔定律的快速迭代使得硬件愈加便宜，使得像Perl这样的语言的执行效率也不再是问题。仅仅三年以后，我可能就会毫不犹豫地使用Python而不是C语言来写SNG。
　　在1997年我学习了Python，这对我来说是一道分水岭。这个语言很美妙就像我早年使用的Lisp一样，而且Python还有很酷的库！甚至还完全遵循了POSIX！还有一个蛮好用的对象系统！Python没有把C语言挤出我的工具箱，但是我很快就习惯了在只要能用Python时就写Python，而只在必须使用C语言时写C。
　　（在此之后，我开始在我的访谈中指出我所谓的“Perl的教训”，也就是任何一个没能实现和C语言语义等价的遵循POSIX的语言都注定要失败。在计算机科学的发展史上，很多学术语言的骨骸俯拾皆是，原因是这些语言的设计者没有意识到这个重要的问题。）
　　显然，对我来说，Python的主要优势之一就是它很简单，当我写Python时，我不再需要担心内存管理问题或者会导致核心转储的程序崩溃对于C程序员来说，处理这些问题烦的要命。
　　而不那么明显的优势恰好在我更改语言时显现，我在90年代末写应用程序和非核心系统服务的代码时，为了平衡成本与风险都会倾向于选择具有自动内存管理但是开销更大的语言，以抵消之前提到的C语言的缺陷。
　　而在仅仅几年之前（甚至是1990年），那些语言的开销还是大到无法承受的；那时硬件产业的发展还在早期阶段，没有给摩尔定律足够的时间来发挥威力。
　　尽量地在C语言和Python之间选择C只要是能的话我就会从C语言转移到Python。这是一种降低工程复杂程度的有效策略。我将这种策略应用在了GPSD中，而针对NTPsec，我对这个策略的采用则更加系统化。这就是我们能把NTP的代码库大小削减四分之一的原因。
　　但是今天我不是来讲Python的。尽管我觉得它在竞争中脱颖而出，Python也未必真的是在2000年之前彻底结束我在新项目上使用C语言的原因，因为在当时任何一个新的学院派的动态语言都可以让我不再选择使用C语言。也有可能是在某段时间里在我写了很多Java之后，我才慢慢远离了C语言。
　　我写这个回忆录是因为我觉得我并非特例，在世纪之交，同样的发展和转变也改变了不少C语言老手的编码习惯。像我一样，他们在当时也并没有意识到这种转变正在发生。
　　在2000年以后，尽管我还在使用CC写之前的项目，比如GPSD，游戏韦诺之战以及NTPsec，但是我的所有新项目都是使用Python的。
　　有很多程序是在完全无法在C语言下写出来的，尤其是reposurgeon以及doclifter这样的项目。
　　由于C言受限的数据类型本体论以及其脆弱的底层数据管理问题，尝试用C写的话可能会很恐怖，并注定失败。
　　甚至是对于更小的项目那些可以在C中实现的东西我也使用Python写，因为我不想花不必要的时间以及精力去处理内核转储问题。这种情况一直持续到去年年底，持续到我创建我的第一个Rust项目，以及成功写出第一个使用Go语言的项目。
　　如前文所述，尽管我是在讨论我的个人经历，但是我想我的经历体现了时代的趋势。我期待新潮流的出现，而不是仅仅跟随潮流。
　　在98年的时候，我就是Python的早期使用者。来自TIOBE的数据则表明，在Go语言脱胎于公司的实验项目并刚刚从小众语言中脱颖而出的几个月内，我就开始实现自己的第一个Go语言项目了。
　　总而言之：直到现在第一批有可能挑战C语言的传统地位的语言才出现。
　　我判断这个的标准很简单只要这个语言能让我等C语言老手接受不再写C的事实，这个语言才“有可能”挑战到C语言的地位来看啊，这有个新编译器，能把C转换到新语言，现在你可以让他完成你的全部工作了这样C语言的老手就会开心起来。
　　Python以及和其类似的语言对此做的并不够好。使用Python实现NTPsec（以此举例）可能是个灾难，最终会由于过高的运行时开销以及由于垃圾回收机制导致的延迟变化而烂尾。
　　如果需求是针对单个用户且只需要以人类能接受的速度运行，使用Python当然是很好的，但是对于以机器的速度运行的程序来说就不总是如此了尤其是在很高的多用户负载之下。
　　这不只是我自己的判断因为拿Go语言来说，它的存在主要就是因为当时作为Python语言主要支持者的Google在使用Python实现一些工程的时候也遭遇了同样的效能痛点。
　　Go语言就是为了解决Python搞不定的那些大多由C语言来实现的任务而设计的。
　　尽管没有一个全自动语言转换软件让我很是不爽，但是使用Go语言来写系统程序对我来说不算麻烦，我发现我写G写的还挺开心的。我的很多C编码技能还可以继续使用，我还收获了垃圾回收机制以及并发编程机制，这何乐而不为？
　　本来我想把Rust也视为“C语言要过时了”的例证，但是在学习并尝试使用了这门语言编程之后，我觉得这种语言现在还没有做好准备。也许5年以后，它才会成为C语言的对手。
　　随着2017结束，我们已经发现了一个相对成熟的语言，其和C类似，能够胜任C语言的大部分工作场景（我在下面会准确描述），在几年以后，这个语言界的新星可能就会取得成功。
　　这件事意义重大。如果你不长远地回顾历史，你可能看不出来这件事情的伟大性。三十年了这几乎就是我作为一个程序员的全部生涯，我们都没有等到一个C语言的继任者，也无法遥望C之后的系统编程会是什么样子的。而现在，我们面前突然有了后C时代的两种不同的展望和未来
　　另一种展望则是下面这个语言留给我们的。
　　我的一个朋友正在开发一个他称之为“Cx”的语言，这个语言在C语言上做了很少的改动，使得其能够支持类型安全；他的项目的目的就是要创建一个能够在最少人力参与的情况下把古典C语言修改为新语言的程序。
　　我不会指出这位朋友的名字，免得给他太多压力，让他做出太多不切实际的保证。但是他的实现方法真的很是有意思，我会尽量给他募集资金。
　　现在，我们看到了可以替C语言实现系统编程的三种不同的可能的道路。而就在两年之前，我们的眼前还是一片漆黑。我重复一遍：这件事情意义重大。
　　我是在说C语言将要灭绝吗？不是这样的，在可预见的未来里，C语言还会是操作系统的内核编程以及设备固件编程的主流语言，在这些场景下，尽力压榨硬件性能的古老规则还在奏效，尽管它可能不是那么安全。
　　现在那些将要被C的继任者攻破的领域就是我之前提到的我经常涉及的领域比如GPSD以及NTPsec、系统服务以及那些因为历史原因而使用C语言写的进程。还有就是以DNS服务器以及邮件传输代理那些需要以机器速度而不是人类的速度运行的系统程序。
　　现在我们可以对后C时代的未来窥见一斑，即上述这类领域的代码都可以使用那些具有强大内存安全特性的C语言的替代者实现。Go、Rust或者Cx，无论是哪个，都可能使C的存在被弱化。
　　比如，如果我现在再来重新实现一遍NTP，我可能就会毫不犹豫的使用Go语言去完成。