“就算我从来没有直接接触过Go并发原语，为了其部署的随意性，我确信我会用Go重写所有我的命令行程序。”
这是我以前说过的话。我认为这句话值得写一篇更详细的博文。
大多深入了解我的人都知道关于我的两件事情：
第二个是Bryan Berry给我贴的标签，引自一个FoodFight早期片段。
有趣的是，这两件事看起来是矛盾的。
我喜欢学习新的编程语言。这定期会给我带来不小的冲击，因为不是个科班的程序员。我没有去上大学学编程（实际上，我根本没有读大学）。我的IT职业生涯几乎100%集中于运维。所有我接触过的东西- QA、DBA、 DEV – 都是源于运维领域，用于满足某些运维操作上的需求。
因此，我惊讶地发现18年后，自己拥有ruby，Python，perl，JAVA的实践知识，并了解其他一些编程语言。我学习新的编程语言主要是因为“技痒”。
我就是在这种情况下，遇到了Go。
如果你没听说过Go，其实有无数的文章，博文和大量新的工具用Go写成。最新的Linux容器周边和新的部署模型就是基于Go的。也有一些相当“大”的用Go编写的项目，如packer等。Mozilla正在用Go构建所有内部工具（据我了解到的是这样的），很多开发者也在转向Go。
你需要知道的是，我并不会因为热度去学习编程语言。比如，我根本就不关心JavaScript和Node。起初，我对Go也没任何兴趣。我认为它只不过是Google的众多学术实验中的一个。何况，如果我要接触一个C风格的编程语言，为什么我不直接学习C语言呢？
实际上，我用这个路子尝试为StormPath写一个PAM模块。虽然也还满意，但项目最终很让人沮丧。
我觉得再尝试Go的一个原因是Go似乎一直都在我周围。这至少给我带来一个竞争者。其次，我使用的部分工具是用Go编写的，我要修正一些这些工具的问题（尤其是这些工具是新项目，必然会有问题需要修复），我确实需要学习这们新的编程语言。
然而，一个工具把我推到了最后一步 – etcd。
你自己可以通读etcd，如果你知道我关于 Noah的历史，你就明白为什么我对它如此感兴趣。
让我自己吃惊的是，我决定可能我自己也要用Go写很多工具。
在Dell Enstratius，我的团队开发的所有内部工具都是用Python写成的。对我们而言，这是一个实用的选择:
为什么我们不用Ruby？考虑到我个人Ruby技能更好并且我们内部也拥有一些Ruby经验。
我们团队考虑了以上所有选项，我们全部同意使用Python。我着手写了一个访问我们API的库。这给我们构建工具提供了基础，同时也作为一个新工具参考项目（如测试，项目结构，可执行脚本等等）。
事情进展的很顺利，直到最近一个客户的情况发生。为了显而易见的原因，我们努力精简依赖。有几个库让这件事变得如此顺利- requests, envoy。我们也喜欢使用 Fabric来封装一些东西。
然后，我们遇到一个状况，一个客户拒绝我们引入外部的包。因此，虽然我们可以“半死”大部分我们的工具，有些事情就是不能工作。追踪传递的依赖真是痛苦。
这就是导致我上面陈述的原因。
Go，虽然不像Python那么容易调试，也还非常容易调试。编译速度很快，测试速度也相当快。但依赖问题才是真正的杀手锏。Go根本就不存在依赖问题。我可以把我编译好的二进制文件任意移动而不出任何问题，也不需要安装运行时。在标准库中也有很多有用的东西。
我也可以在osx，windows或者linux上不做任何更改的编译相同的代码。这也比我们使用Python方便。
和我说的一样，虽然我现在写的工具一点也没用上Go的高级并发特性，但是Go确实拥有这个特性，如果我要用，还是很好的。
我们还没有转向用Go来构建工具，但我很可能会用的。我已经致力于用Go来写一个我们API的封装，因此我也可以重写其他一些工具。在依赖受限的系统上，这种做法还是很好用的。这就是这篇博文的重点所在。
如果你的工作和运维相关，学习Go没什么坏处。
语法简洁。C带来的头痛的问题基本都会消失不见。同时，你也不用担心系统的Python或者Ruby版本是多少。Go是一个开发bootstrap工具的绝妙语言——因为bootstrap工具的运行环境没有任何安装好的依赖。如果你开始使用像docker, packer 或者etcd的工具，Go也会很有帮助。
试试Go吧。