今天我们在 2017 年底聚集在这里，下一项我们应该为某些暴躁的团体发声，如 Go 团队，但事实并非如此。 Go 这个项目漏洞百出，我甚至可以想象出它失败的各种可能，Go 团队太过固执独断，即使几乎整个用户群体都认为 Go 需要做出改变了，Go 团队也无动于衷，这是个大问题。 一旦发生故障， GC 发生延迟或者用牺牲生产量来弥补延迟，但无论如何，它都会严重影响到这种语言的应用，大幅缩小这种语言的适用范围。
即便如此，在 Go 的设计中，还是有一个我颇为认同的远大战略目标，想要理解这个目标，我们需要回想一下如果想要取代 C 语言，要面临的短期问题是什么。同我之前提到的，随着项目计划的不断扩张，故障率也在持续上升，这其中内存管理方面的故障尤其多，而内存管理一直是崩溃漏洞和安全漏洞的高发领域。
我们现在已经知道了两件十分重要的紧急任务，要想取代 C 语言，首先要先做到这两点：（1）解决内存管理问题；（2）降低由 C 语言向本语言转化时所需的转入成本。纵观编程语言的历史——从人类行为学的角度来看，作为 C 语言的准替代者，如果不能有效解决转入成本过高这个问题，那他们所做的其他部分做得再好都不算数。相反的，如果他们把转入成本过高这个问题解决地很好，即使他们其他部分做的不是最好的，人们也不会对他们吹毛求疵。
这正是 Go 的做法，但这个理论并不是完美无瑕的，它也有局限性。目前 GC 延迟限制了它的发展，但 Go 现在选择照搬 Unix 下 C 语言的传染战略，让自身语言变成易于转入，便于传播的语言，其繁殖速度甚至快于替代品。但从长远角度看，这并不是个好办法。
五年后 Rust 能发展的怎样还是个问题，如果他们愿意改变，我建议他们重视转入成本问题。以我个人经历来说，由 C 语言转入 Rust 语言的能量壁垒使人望而却步。如果编码提升工具比如 Corrode 只能把 C 语言映射为不稳定的 Rust 语言，但不能解决能量壁垒的问题；或者如果有更简单的方法能够自动注释所有权或试用期，人们也不再需要它们了——这些问题编译器就能够解决。目前我不知道怎样解决这个问题，但我觉得他们最好找出解决方案。
在最后我想强调一下，虽然在 Ken Thompson 的设计经历中，他看起来很少解决短期问题，但他对未来有着极大的包容性，并且这种包容性还在不断提升。当然 Unix 也是这样的， 它让我不禁暗自揣测，让我认为 Go 语言中令人不快的地方都其实是他们未来事业的基石（例如缺乏泛型）。如果要确认这件事是真假，我需要比 Ken 还要聪明，但这并不是一件容易让人相信的事情。
