不折腾那就安安心心的 ubuntu ，别的都不靠谱。
别再折腾系统本身的事情了，把时间都拿来做自己的事，做项目。

店大欺客。

推荐楼主看看 Ubuntu Make

@LINEX 但 Go 有默认值，很多数据结构默认值就不允许为 nil ，根本没有 java/c++里面这种 null 带来的比较严重的问题，只是写起来很罗嗦，需要改进。但这个问题不是 null 最大的危害所在。你只觉得 java 里的 null 判断比较罗嗦，但其实仅仅是罗嗦的话，这个问题也就不会是 one billion dollar mistake 了。

guava 目前是最靠谱的选择。

Go Team 的 Dave Cheney(就是 ubuntu juju 那个大胡子)好像要来。

和 gomobile 一回事，曲线救国(很多语言要上 android 都得这么干)。 Swift 和 Go 都是编译为 2 进制，只需支持 NDK 。而其他语言只能傍 jvm ， ART 虚拟机。 kotlin 显然属于后者。

除非重写 SDK ，否则没多大意思。 UI 部分还得用官方 SDK 支持的语言，后台逻辑部分可以用你想要的语言（比如以编译成库的形式，以供调用）。

而重写 SDK 还得看 android team 那票人怎么想的，有没有要换 java 的意思。目前看不到任何迹象(至少 oracle 的官司未宣判之前，谷歌是不会有任何表态的)。重写 SDK 至少需要 2-3 年时间，成熟完善需要时间就更久了。

当然还有另一条路，就是 reactive 那种的。

sublime text 3 也快要开源了。

unix haters book 上面罗列的很多问题现在的 unix 已经修复，在 linux 上面也早已不复存在。
看完这本书推荐楼主再看看《 unix 编程艺术》这本书，这本书里面 windows ， mac OS 甚至在当时经典而超前的 BeOS 都有涉及，看完就知道 unix 怎么走到今天的。比如有的东西(x window system)如今显得落后了，但其中的思想还是很经典的。 unix 的流行就像病毒那样流行或者说是传染起来的，第一个病毒也是 unix hacker 搞出来的（ hacker 以前是编程厉害的大牛的称谓，现在和骇客，黑客这些联系起来了）。

另外还有一本书“集市和大教堂”，很精准的阐释了商业公司运作和开源社区的模式的区别。
其实你仔细观察下这几年开源社区的蓬勃发展，各种开源软件的出现，以及 github 的火热，和当年那些 unix hackers 非常相似，火热的造轮子，然后发布出去被膜拜，接着大家一起造，形成一个个社区，只不过当时没有 github ，主要是在邮件列表上进行，很多经典的大辩论都可以在归档的邮件列表中查到(比如 RSM ，比如 linus 和 minix 之父的辩论等等)。 unix 下面一大堆经典的工具链就是这么不断的造出来并延续至今的。

要说它的优势是什么？为什么会流行？我觉得最大的优势就是自由，任何厉害的人可以在上面证明自己，信誉驱动，这是 geek 和 hackers 们的天堂。而早期的开荒者都是 hackers ，那时候还不会考虑什么客户啦，用户体验啦之类的东西。
当然这个传统和风气沿袭至今，也导致 linux 桌面一直很难有一个统一的好用的桌面系统出来，因为文化差异太大。

楼主说的完美的问题。
计算机科学到底算不算科学？软件工程到底算不算工程？如果算科学那么对比经典物理学如何呢？如果算工程，那么可靠性如何？为何无法避免 bug ？软件分分秒秒都在出 bug ，建造的房子如果也这么出 bug 那早就出人命了。所以，你想找一个完美的软件系统是不可能的，根本上也是解决不了的。你越追求完美，它越没有实用价值。

" cp 、 mv 、 rm ，都是因为当初是电传终端，为了提高效率而采用的缩写，为什么就没有某个发行版本，把这些改成大家能够理解的命令？ copy 、 move 、 remove 不也挺好么？ "
=======================================
不是为了提高效率而缩写，而是本身就是这个命名风格， unix/linux 系的东西都是这种命名风格，沿用至今。对比下 linux api 和 windows 的 api 的风格差异你会一目了然。说不上谁好谁坏。现在有 IDE 补全还好说，以前那种命令行环境下，屏幕又小，敲那么多字母要敲死人的。以前的键盘按键分布也和现在的 wasd 键盘有差别，所以有历史遗传的因素在里面。为什么不改过来？因为没看到足够的好处或者非改不可的必要。

至于有了鼠标，图形界面是不是命令行工具就不需要了？肯定不是。有些事情命令行还是比点鼠标要快的，而且使用起来更灵活。有些安全性较高的地方，后台是不允许有图形环境的， bug 多，潜在的安全漏洞也多。

其实你在心里已经在其实农民了。

@jjx 我没说不能，我只说很麻烦。工具让人变懒是好事，希望有更多这样的工具出现，其实包管理的问题也可以，也应该给通过工具去解决，这种脏活，累活本身就是计算机发明出来该替人做的事，不应该把人的精力和兴趣耗在这些琐碎的事情上。
很高兴的看到，这几年无论是动态语言还是前端，也开始重视静态类型以及工具的作用了。

@shyling 可以用来释放资源的(所以说它和 RAII 有相似的地方)。比如打开文件后面要关闭文件。
：= struct{}和：= &struct{}, 一个是值拷贝一个是指针拷贝(如果你觉得拗口，就暂时按引用类型理解， slice ， map 这些都可以这么理解)，因为有的 struct 可能会非常大，所以为了减少开销，返回一个指针(或者就叫引用吧)。
n := &struct{}和 n := new(struct)是一样的。
的确，省略 new 没省略这个过程，但代码的可读性和连贯性上会大打折扣。 reactive 风格的编程更靠近 FP 语言，在这点上，其实 javascript 比 java 做的要好(JS 比 java 更 FP 一点)。我有个大胆的猜想(java 某一天也会去掉 new ？)
user definded 类型确实不支持，其实这就是不支持泛型的问题。
一切皆 OO 的语言几乎都没有指针，而且默认是按引用传递，而系统编程语言比如(c/c++，算半个系统编程语言的 Go)都是按值传递多一点。这也就造成了很多的不同。比如你可以"string".Replace ， python 里面你可以直接各种精度的整数相加，因为这些都是一个 int 对象，而不是具体的值类型，是有抽象在里面的。不能说说谁好谁坏，根据不同的使用场景各有自己的优劣，比如做 application 层面的开发， OO 这种引用类型的使用的多一些，而系统编程语言后者多一些，为了性能以及内存开销低一些，比如游戏开发里面甚至会有专门的值类型，比如支持 SIMD 数值类型。
Reader 是一个接口， size()是实现了 Reader 接口的一个方法。 Go 的接口是非侵入式的，组合起来非常自由，但也有很多人吐槽的，不知道谁实现了谁的问题。

@WildCat 非要按照引用类型的本义去理解(比如 c++里的那种)，那么 Go 是没有引用类型的，只是 js/python/ruby/java/php 的程序员都不使用指针，都习惯了引用类型，所以 Go 的 map ， slice 那些叫引用类型也成。
但 Go 是按值传递，这点和它们有很大的不同，和 c++更接近。比如 c#是两者都支持(有 struct)，但却更接近 java/python 。。。这些。

Go 是续命还是萎靡我不做预测，但拿语法丑陋，缺少一大堆特性来说事，我只能说：你到现在还没搞懂： Go 为何会有人在用它。而这篇文章的作者显然是给出了用 Go 的比较靠谱的理由。
docker 再火其实对 Go 本身影响不大，因为大家都在用 docker(各种语言都支持)，而不是用 Go 语言其重写一个又一个新的 docker 。而 Go 自身真正吸引一部分人去用它编程的，不是 docker ，而是服务端开发。

最后： Go 现阶段不要盲目的入坑(写些自己的小项目，小工具除外)， Go 其实不太适合新手。 Go 作出的一些语法特性上的牺牲和一些妥协只有在工程上，具体项目上能体会到，撞了墙之后才能有深刻体会。不要被 Go 的语法简洁，上手快等等特点给误导。也就是说：不用只看其一面。

希望这不是引战贴，而是解惑贴，各取所需就行了。

@nareix 写问题不大，最麻烦的是重构。

@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).

@zonghua 当然， Go 编译速度很快（ go build go run ，部署很简单，就一个二进制文件，没什么依赖。不过没有动态语言那种 REPL ）。其实现在 github 上面很多 Go 写的东西都是这种类型的。类似于脚本语言去做的事情但同时又想要性能以及类型检查。

Go 语言。
你想要的就是写一些命令行下的小工具，又是静态类型的，开发速度快的，想了下那就只有 Go 了。

SYN 和 FIN 是建立连接，握手阶段才使用。
ACK 为 1 表示这是一个确认帧。 ack 和 seq 是对应的帧序号，两者是对应的。 A 发送帧给 B ， B 收到 A 发送的帧之后向 A 发送确认帧，编号为已正确收到的最后一帧的下一个帧(也就是期望收到的帧的编号)。所以 B 的 ack 等于 A 的 seq+1 。

groovy 怎么样？不怎么样。
但 Gradle 很吊。 long live Gradle

java Go