读 《我为什么放弃Go语言》 有感

Posted 2020-07-03 simplelovecs

　　最近又熟悉了下go语言，发现go语言还有许多设计不好的地方，然后又读到了《我为什么放弃Go语言》这篇文章， 对于某些方面，我还是比较认同的。 

这篇文章总结了十六点，如下：

1.1 不允许左花括号另起一行

1.2 编译器莫名其妙地给行尾加上分号

1.3 极度强调编译速度，不惜放弃本应提供的功能

1.4 错误处理机制太原始

1.5 垃圾回收器（GC）不完善、有重大缺陷

1.6 禁止未使用变量和多余import

1.7 创建对象的方式太多令人纠结

1.8 对象没有构造函数和析构函数

1.9 defer语句的语义设定不甚合理

1.10 许多语言内置设施不支持用户定义的类型

1.11 没有泛型支持，常见数据类型接口丑陋

1.12 实现接口不需要明确声明

1.13 省掉小括号却省不掉花括号

1.14 编译生成的可执行文件尺寸非常大

1.15 不支持动态加载类库

1.16 其他

• 不支持方法和函数重载（overload）
• 导入pkg的import语句后边部分竟然是文本（import ”fmt”）
• 没有enum类型，全局性常量难以分类，iota把简单的事情复杂化
• 定义对象方法时，receiver类型应该选用指针还是非指针让人纠结
• 定义结构体和接口的语法稍繁，interface XXX{} struct YYY{} 不是更简洁吗？前面加上type关键字显得罗嗦。
• 测试类库testing里面没有AssertEqual函数，标准库的单元测试代码中充斥着if a != b { t.Fatal(...) }。
• 语言太简单，以至于不得不放弃很多有用的特性，“保持语言简单”往往成为拒绝改进的理由。
• 标准库的实现总体来说不甚理想，其代码质量大概处于“基本可用”的程度，真正到企业级应用领域，往往就会暴露出诸多不足之处。
• 版本都发展到1.2了，goroutine调度器依旧默认仅使用一个系统线程。GOMAXPROCS的长期存在似乎暗示着官方从来没有足够的信心，让调度器正确安全地运行在多核环境中。这跟Go语言自身以并发为核心的定位有致命的矛盾。（直到2015年下半年1.5发布后才有改观）
• 官方发行版中包含了一个叫oracle的辅助程序，与Oracle数据库毫无关系，却完全无视两者之间的名称混淆。