无情编纂的好奇案例

在电影里2001年:太空漫游计算机程序HAL 9000变得流氓,对太空船的船员毫不留情这正是新人的到来去编程语言必须感受到。

自2009年推出以来,该语言已经产生了数十亿字节的关于其非常自以为是的哲学的在线辩论由于它是静态编译的语言,因此它具有编译器就像HAL一样,Go编译器非常顽固 - 我敢说 -无情

以案例为例这可怜的开发者谁也不相信Go编译器会如此残酷:

TBH,这是我在编程语言中见过的最愚蠢的事情

奇怪,我想空引用的发明在这里是明显的赢家无论如何,是什么让那个家伙宣布终于达到了愚蠢的顶峰?Go编译器不允许您使用未使用的导入运行代码。

At this point, you may wonder why the compiler is so adamant about that? As far as I know, it's unique in that regard例如,为什么它在这种情况下不会只显示警告?

让我们问一下应该知道的人:语言创造者其中,你会发现两个计算机科学的传说:Rob Pike和Ken Thompson两者都参与了Unix的创建让我们来看看他们的官方最佳实践指南有效的去得到答案:

导入包[...]而不使用它是错误的未使用的导入会破坏程序并减慢编译速度。

很公平没有人喜欢慢速编译器你会在网上找到令人难以置信的快速Go的编译器它的工作流程几乎就像一个动态类型的语言,具有闪电般快速的反馈循环。

这不是偶然的。

实际上,它是语言的核心设计原则之一不允许未使用的进口只是这个难题的一部分为了瞥一眼它的起源,请查看以下摘录采访Rob Pike

起点是编译时间长- 对于Google的一些大型软件,即使使用我们的大型分布式编译集群,构建时间也可能过长C和C ++中的依赖关系管理(或缺少关系)会导致编译器中的代码太多。你可能会说Go是在等待大量编译的时候构思出来的。

我们都看过无数的模因开发人员在等待编译器时所做的事情- 但这个肯定是蛋糕通过这个背景故事,您可以理解为什么Go是从头开始构建的,以便尽快编译为了达到目的,你必须做出牺牲不允许浪费像通过编译器管道的未使用的导入一样,该过程效率更高But to an outsider, only seeing the tip of the iceberg, this may look like "the most stupid thing in a programming language".

但是冰山变得更加深刻。

追求最快的编译器可能会产生另一个无情的决定,它会严重影响每个应用程序的设计:not allowing circular package dependencies.当包一个取决于包装反之亦然,我们有一个循环包依赖或导入循环为此,Go会比你说'循环'更快地向你抛出一个错误。

从设计角度来看,包级别的循环是坏消息它紧紧地结合了那个周期中的一切,使其更难以改变和推理有趣的是,许多其他编程语言对导入周期非常宽容例如,在Java中,您甚至可能根本没有注意到代码中存在循环那么为什么Go如此不屈不挠?

再次编译速度Go使用了一次编译器它只处理每个源文件一次因此它不像Java那样复杂多通道编译器- 但速度很快这个决定也从根本上影响Go的设计它迫使语言变得简单:语言规范可以在不到一天的时间内轻松阅读,而您需要一棵古老的红木树来为Java的规范生成足够的纸张。

从技术上讲,我们还没有回答为什么Go不能在开发过程中使用警告幸运的是,去常见问题作用:

有些人要求使用编译器选项来关闭这些检查,或者至少将它们减少为警告但是,没有添加这样的选项,因为编译器选项不应该影响语言的语义,因为Go编译器不报告警告,只报告阻止编译的错误。

毕竟你读完了,这应该不足为奇将这些错误转化为警告将严重破坏语言的核心理念,重点是速度和简单性因此,拒绝任何此类请求是唯一的权利。

在这一点上值得一提的是,在开发过程中可以轻松解决这个问题惯用的方法是使用下划线字符作为导入名称:

import _“fmt”

这样,编译器就会忽略它但是出现了一种更聪明的方式:(现在是官方的)命令工具goimports自动添加缺失的导入并删除未使用的导入您可以配置您选择的编辑器,以便在保存文件后运行它正如您现在所期望的那样,它是闪电般快速的它使开发人员退出循环,从一个工具解决另一个工具的问题我不禁微笑着讽刺而又绚丽的光彩。

正如我们所看到的,Go编译器可能被认为是无情的At least HAL 9000 had a gentle voice to soften the blow! But as you have seen, it has the very best intentions要获得简单和快速的回​​报,这是一个很小的代价最终,您的代码和工作流程对它来说都更好。


评论由Disqus