我为什么放弃Go语言

[十年来，你坚持了什么，放弃了什么]十年来，你坚持了什么，放弃了什么？十年了，你坚持的东西有哪些呢，你还在坚持什么，如果能回到十年前，你会对自己说什么呢？最近在微博上有一个帖子：十年了，你坚持的东西有哪些呢，你还在...+阅读

有好几次，当我想起来的时候，总是会问自己：我为什么要放弃Go语言？这个决定是正确的吗？是明智和理性的吗？其实我一直在认真思考这个问题。

开门见山地说，我当初放弃Go语言（golang），就是因为两个“不爽”：第一，对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 不支持动态加载类库

为什么我不会舍弃Python投奔Go语言

在Go语言中，规定的方式是，函数返回错误信息。这没什么。如果一个文件并不存在，op.Open函数会返回一个错误信息。这没什么。如果你向你一个中断了的网络连接里写数据，net.Conn里的Write方法会返回一个错误。这没什么。这种状况在这种程序中是可以预料到的。这种操作就是容易失败，你知道程序会如何运行，因为API的设计者通过内置了一种错误情况的结果而让这一切显得很清楚。

从另一方面讲，有些操作基本上不会出错，所处的环境根本不可能给你提示错误信息，不可能控制错误。这才是让人痛苦的地方。典型的例子；一个程序执行

x[j],j值超出数组边界，这才痛苦。像这样预料之外的麻烦在程序中是一个严重的bug，一般会弄死程序的运行。不幸的是，由于这种情况的存在，我们很难写出健壮的，具有自我防御的服务器——例如，可以应付偶然出现的有bug的HTTP请求处理器时，不影响其他服务的启动和运行。为解决这个问题，我们引入了恢复机制，它能让一个go例程从错误中恢复，服务余下设定的调用。然而，代价是，至少会丢失一个调用。这是特意而为之的。引用邮件中的原话：“这种设计不同于常见的异常控制结构，这是一个认真思考后的决定。我们不希望像java语言里那样把错误和异常混为一谈。”

我刚开始提到的那篇文章里问“为什么数组越界造成的麻烦会比错误的网址或断掉的网络引出的问题要大？”答案是，我们没有一种内联并行的方法来报告在执行x[j]期间产生的错误，但我们有内联并行的方法报告由错误网址或网络问题造成的错误。

使用Go语言中的错误返回模式的规则很简单：如果你的函数在某种情况下很容易出错，那它就应该返回错误。当我调用其它的程序库时，如果它是这样写的，那我不必担心那些错误的产生，除非有真正异常的状况，我根本没有想到需要处理它们。

有一个你需要记在心里的事情是，Go语言是为大型软件设计的。我们都喜欢程序简洁清晰，但对于一个由很多程序员一起开发的大型软件，维护成本的增加很难让程序简洁。异常捕捉模式的错误处理方式的一个很有吸引力的特点是，它非常适合小程序。但对于大型程序库，如果对于一些普通操作，你都需要考虑每行代码是否会抛出异常、是否有必要捕捉处理，这对于开发效率和程序员的时间来说都是非常严重的拖累。我自己做开发大型Python软件时感受到了这个问题。

Go语言的返回错误方式，不可否认，对于调用者不是很方便，但这样做会让程序中可能会出错的地方显的很明显。对于小程序来说，你可能只想打印出错误，退出程序。对于一些很精密的程序，根据异常的不同，来源的不同，程序会做出不同的反应，这很常见，这种情况中，try

catch的方式相对于错误返回模式显得冗长。当然，Python里的一个10行的代码放到Go语言里很可能会更冗长。毕竟，Go语言主要不是针对10行规模的程序的。

就是要说明这一点：Go语言程序员认为，把error作为一种内置的类型是非常重要的。

Go语言为啥火不起来

作者：luikore

来源：知乎

著作权归作者所有

Rust 和 Nim 确实好呀

Rust 可以说是 D 语言二代目，没有 D 里的一些经验主义设计，而且更函数式，作为 a better C++ 当之无愧. Pattern matching, Block, Generic 这些东西， Go 有么？不好的地方是集成 feature 略贪心，指针那么多类型是有道理但是学习者容易被吓跑.

Nim 不是函数式的，但 Nim 支持卫生宏，可以做 AST 重写，可以自定编译规则，是静态语言中的黑客语言有木有！自定编译规则甚至可以编译出比 C 代码还快的结果，作为 a better C 当之无愧. 人家 GC 可以手动步进的啊，想要什么 feature 自己加（list comprehension？没问题），加个 const 就可以做编译期计算了（想想 C++ 和 D 里复杂难以掌握的 template 和 static if 多蛋疼），改写 AST 的 pattern language 也是简单易懂（想想 Java 的 annotation processing tool 怎么用的就蛋碎...），更重要的一点：没有那么多哲学骑着你禁止你怎么怎么做， Go 能么？

人类思维有个巨大的缺点就是从众定势，当然社区大了开发者多了语言会更容易成熟和变得实用，但如果更多人懂得多了解学习，理性比较而不是跟风，现在的编程语言可以发展得更好.