我每天的工作都用go语言,我对它很熟悉,但是我并不喜欢go语言,也不懂为什么这语言能火,下面从几个角度阐述。
我从没见过一门语言能引发如此公然地敌对开发者工程学。举个例子,Rob Pike(go语言之父)多次公然反复地反对任何关于go语言平台的语法高亮,而且对于很多不错的用户问题,他的公开回答是傲慢而无礼的。
Gofmt编写出来就是为了减少关于代码格式化的无意义的讨论。我很遗憾的说,再多的关于语法高亮的无意义的讨论都是无用功,或者我更愿意称这为“spitzensparken blinkelichtzen”(用于嘲讽输错命令的用户)。
上述来自于 2012 Go-Nuts thread,除此之外
语法高亮是幼稚的,我三岁学算术的时候都不用彩色棒了(http://en.wikipedia.org/wiki/Cuisenaire_rods)。现在我只用单色的数字符号。
问题在于Rob所关心的人之中没人经历过阅读困难、视觉障碍、联觉。Rob对这个想法的不认可使得Go的官方网站和文档编写一直处于强调自由状态。
Go团队不同于Rob Pick,但是他们在其他方面分享了他对人机工程学的看法,在一个关于union/sum类型的讨论中,用户ianlancetaylor直接拒绝了这一要求,他特别指出了一个符合人体工程学的好处,并认为它太微不足道,不值得费心:
从开放源码发行版之前开始,这在过去已经讨论过好几次了。过去的共识是sum类型不会向接口类型添加太多内容。一旦你把它们都整理好,最后你会得到什么,如果一个接口类型,编译器检查你已经填入了一个类型开关的所有情况。对于一种新的语言变化来说,这是一个相当小的好处。
可能失败的操作的标准Go方法涉及返回多个值(不是元组; Go没有元组),其中最后一个值是类型错误,这是一个接口,其nil值表示“没有发生错误”。
因为这是一个约定,所以它在Go的类型系统中是不可表示的。没有通用类型表示错误操作的结果,可以在其上编写有用的组合函数。此外,它并没有严格遵守:除了良好的意义之外,其他任何东西都不会阻止程序员在某些其他位置返回错误,例如在返回值序列的中间,或者在开始时 - 因此处理错误的代码生成方法是也充满了问题。
在Go中,不可能以任何比一些变化更简洁的方式构成错误的操作
a, err := fallibleOperationA() if err != nil { return nil, err } b, err := fallibleOperationB(a) if err != nil { return nil, err } return b, nil
在其他语言中,这可以不同地表达为
a = fallibleOperationA() b = fallibleOperationB(a) return b
在有例外的语言中,或作为
return fallibleOperationA() .then(a => fallibleOperationB(a)) .result()
在具有可以对案例值进行操作的抽象的语言中。
这具有实际影响:执行长序列的错误操作的代码花费大量的打字工作来编写(即使编辑器支持生成分支),并且需要大量的认知努力来阅读。风格指南有所帮助,但混合风格使其变得更糟。考虑:
a, err := fallibleOperationA() if err != nil { return nil, err } if err := fallibleOperationB(a); err != nil { return nil, err } c, err := fallibleOperationC(a) if err != nil { return nil, err } fallibleOperationD(a, c) return fallibleOperationE()
如果你嵌套它们,上帝会帮助你,或者想要做一些比将错误传回堆栈更有趣的事情。
评论删除后,数据将无法恢复
评论(5)