@
shyling defer 有什么不好的吗？具体说说。它类似 RAII 但有所不同。有人用 defer 模拟过延迟计算的特性，实现过一个定时器，这东西有可取之处。
panic 的使用原则就是“不 panic 就尽量不要使用 panic ，但它是个 panic 的时候，要尽早 panic ”。 erlang 里面也有类似的箴言，“尽早的出错”，等拖到后面一个都捕获不到，服务器挂了后抓瞎，不知道原因在哪里。
n:=struct{}就是一个初始化声明，有了&struct{}，基本上就用不到“ new ”这个关键字了， n 以后说不定会删掉 new 。 java 里面一堆的 new ，很恶心的，现在新设计的很多语言都是没有 new 的。如果你搞 reactive 风格的编程， new 的恶心程度堪比 call back hell ；
map[string]string 就是 map<string,string>，前者是扁平形的，后者是嵌套的，你多嵌套几层，从可读性上你会发现前面的写法还是有可取之处的。另外就是省了个尖括号， Go 是能省就省。比如很多语言的 list 使用"[", "]"来表示，而 Go 里面 struct ， map ， slice 统统用"{ " , "}"。
"string".Replace ？那你是不是还想要
Int.xxx ，这典型的一切皆 OO 风格。 Go 当初定位是系统编程语言，它不如 c/c++那么底层，但又比 java 底层一些，比 python/ruby/js/php 这些动态语言来说，代码书写的自由度上肯定不能比，但天下没有免费的午餐。 Go 一切是按值传递而非引用(slice 实际上不能说是引用类型， Go 里面没有引用的说法。传递的是指针的值)。那么为何要保留指针？为何不那么 OO ？其实都是一种折衷的选择。因为它当初的定位是系统编程，性能和开销需要有个限度。例子: java 9 或者 10 要实现的 value type 就是这个情况的最好说明。
@
ALL楼主列举的优点是从实战的角度去谈，说的很客观。实际上 Go 的安利文基本上都属于这种。你见过哪篇 Go 的安利文是“ Go xxx 特性多么牛”，“ Go 又实现了个性特性，能 XXX ”....... 没有，一个也没有。
说 Go 好的基本都是从工程化，项目的角度去谈，比如它的标准库很不错，部署很方便，编译快开发效率高有种使用动态语言的感觉，写并发变得简单了些等等。但很多人却不从这个角度去谈，而是专挑语言本身的问题。语法怎么怎么地？没有 xxx 特性，你看看谁谁谁写的文章大骂 Go 是垃圾等等等，这些东西站的角度不同，看到的结果自然会不同。 Go 优缺点并存，你看不到它好的只看到缺点，更是用都没用过，那还能说出什么有意义的东西出来。比如上面有人不断提到“ Go 没有泛型”，这是不是个问题？当然是。但楼主的这个贴，以及所引用的场景，写 10 万行代码都不会有一次要用到泛型的。再就是包管理的问题， Go 做的很差。这个可以展开说，尽情吐槽，有理有据都成。但 Go 的包管理一定不会做成 npm 以及 Rust 的 Cargo 那样的。为何 Go 一开始没有包管理？因为 google 内部自己就从来不用这玩意儿，所以 Go 的开发者也就没有搞这些。实际上 1.5 ， 1.6 包管理的进展到实现大部分都是 Go 社区那些人搞的(比如 vendor 那个具体方案就是非 google 的人提出的被采纳了）。
最后，心态都开放一点， Go 不能完全取代 node(至少在 web 开发这一块， Go 没有机会。服务端 Go 很擅长)，不用这么怕，充满火药味，它们都是工具，让你的生活变得简单些。这里有个 2 年前的 Go 和 Ruby 的撕 b 贴，很长但没有那么浓的火药味，回帖质量挺高的(
https://ruby-china.org/topics/14407)。转一段 The Little Go Book 上的一段话，看看 Go 与 ruby,python ， c/c++/java 间的关系， Go 目前到底适用用来做些什么事情。
Go was built as a system language (e.g., operating systems, device drivers) and thus aimed at C and C++ developers.
According to the Go team, and which is certainly true of me, application developers, not system developers, have
become the primary Go users. Why? I can ’ t speak authoritatively for system developers, but for those of us building
websites, services, desktop applications and the like, it partially comes down to the emerging need for a class of
systems that sit somewhere in between low-level system applications and higher-level applications.
Maybe it ’ s a messaging, caching, computational-heavy data analysis, command line interface, logging or monitoring.
I don ’ t know what label to give it, but over the course of my career, as systems continue to grow in complexity
and as concurrency frequently measures in the tens of thousands, there ’ s clearly been a growing need for custom
infrastructure-type systems. You can build such systems with Ruby or Python or something else (and many people
do), but these types of systems can benefit from a more rigid type system and greater performance. Similarly, you
can use Go to build websites (and many people do), but I still prefer, by a wide margin, the expressiveness of Node or
Ruby for such systems.
There are other areas where Go excels. For example, there are no dependencies when running a compiled Go program.You don ’ t have to worry if your users have Ruby or the JVM installed, and if so, what version. For this reason, Go is becoming increasingly popular as a language for command-line interface programs and other types of utility programs you need to distribute (e.g., a log collector).