锐客网

  1. 首页 > 睿知 > it技术 > >

go语言还有gc go 语言 gui( 三 )

IT技术语言


所以, 我觉得Go用户不用纠结BOM这个无关紧要的东西.
在上一个10年，我（Liigo）在我所属的公司里 ， 深度参与了两个编程语言项目的开发 。我想，对于如何判断某个编程语言的优劣，或者说至少对于如何判断某个编程语言是否适合于我自己，我应该还是有一点发言权的 。
第1节：我为什么对Go语言不爽？
Go语言有很多让我不爽之处 ， 这里列出我现在还能记起的其中一部分，排名基本上不分先后 。读者们耐心地看完之后，还能淡定地说一句“我不在乎”吗？
1.1 不允许左花括号另起一行
关于对花括号的摆放，在C语言、C++、Java、C#等社区中，十余年来存在持续争议，从未形成一致意见 。在我看来，这本来就是主观倾向很重的抉择，不违反原则不涉及是非的情况下，不应该搞一刀切，让程序员或团队自己选择就足够了 。编程语言本身强行限制，把自己的喜好强加给别人，得不偿失 。无论倾向于其中任意一种 ， 必然得罪与其对立的一群人 。虽然我现在已经习惯了把左花括号放在行尾，但一想到被禁止其他选择，就感到十分不爽 。Go语言这这个问题上，没有做到“团结一切可以团结的力量”不说，还有意给自己树敌 ， 太失败了 。
我觉得Go最伟大的发明是 go fmt, 从此Go用户不会再有花括弧的位置这种无聊争论了(当然也少了不少灌水和上tiobe排名的机会).
是这优点, Swift 语言也使用和 Go 类似的风格(当然楼主也可能鄙视swift的作者).
1.2 编译器莫名其妙地给行尾加上分号
对Go语言本身而言，行尾的分号是可以省略的 。但是在其编译器（gc）的实现中，为了方便编译器开发者，却在词法分析阶段强行添加了行尾的分号，反过来又影响到语言规范，对“怎样添加分号”做出特殊规定 。这种变态做法前无古人 。在左花括号被意外放到下一行行首的情况下，它自动在上一行行尾添加的分号，会导致莫名其妙的编译错误（Go 1.0之前） ， 连它自己都解释不明白 。如果实在处理不好分号，干脆不要省略分号得了；或者，Scala和JavaScript的编译器是开源的 ， 跟它们学学怎么处理省略行尾分号可以吗？
又是楼主的 个人主观感受, 不过我很喜欢这个特性. Swift 语言也是类似.
1.3 极度强调编译速度，不惜放弃本应提供的功能
程序员是人不是神，编码过程中免不了因为大意或疏忽犯一些错 。其中有一些，是大家集体性的很容易就中招的错误（Go语言里的例子我暂时想不起来，C++里的例子有“基类析构函数不是虚函数”） 。这时候编译器应该站出来，多做一些检查、约束、核对性工作，尽量阻止常规错误的发生，尽量不让有潜在错误的代码编译通过，必要时给出一些警告或提示 ， 让程序员留意 。编译器不就是机器么 ， 不就是应该多做脏活累活杂活、减少人的心智负担么？编译器多做一项检查 ， 可能会避免数十万程序员今后多年内无数次犯同样的错误 ， 节省的时间不计其数，这是功德无量的好事 。但是Go编译器的作者们可不这么想，他们不愿意自己多花几个小时给编译器增加新功能，觉得那是亏本，反而减慢了编译速度 。他们以影响编译速度为由，拒绝了很多对编译器改进的要求 。典型的因噎废食 。强调编译速度固然值得赞赏，但如果因此放弃应有的功能，我不赞成 。
编译速度是很重要的, 如果编译速度够慢, 语言再好也不会有人使用的.
比如C/C++的增量编译/预编译头文件/并发编译都是为了提高编译速度.
Rust1.1 也号称 比 1.0 的编译时间减少了32% (注意: 不是运行速度).

推荐阅读


上一篇：包含外部js变量传入html的词条

下一篇：便宜的steam赛车游戏，steam哪款赛车游戏好玩