“就算我从来没有直接接触过Go并发原语，为了其部署的随意性，我确信我会用Go重写所有我的命令行程序。”
这是我以前说过的话。我认为这句话值得写一篇更详细的博文。
NKOTB大多深入了解我的人都知道关于我的两件事情：
对技术决策，我是相当实用主义并有点保守的。
我是一个语言旅行者
第二个是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似乎一直都在我周围。这至少给我带来一个竞争者。其次，我使用的部分工具是用Go编写的，我要修正一些这些工具的问题（尤其是这些工具是新项目，必然会有问题需要修复），我确实需要学习这们新的编程语言。
然而，一个工具把我推到了最后一步 – etcd。
你自己可以通读etcd，如果你知道我关于 Noah的历史，你就明白为什么我对它如此感兴趣。
让我自己吃惊的是，我决定可能我自己也要用Go写很多工具。
关于实用主义在Dell Enstratius，我的团队开发的所有内部工具都是用Python写成的。对我们而言，这是一个实用的选择:
在我们产品支持的平台上Python的依赖最小（它也会在我们客户的系统上）。
对新的开发者（我们团队确实有那么几个）来说，Python用正确的方式进行了严格规定。
由于上一条，不管你的Python水平如何，你都可以经常审阅和学习别人的代码。
为什么我们不用Ruby？考虑到我个人Ruby技能更好并且我们内部也拥有一些Ruby经验。
你看过Ruby发行版的状态么？
我们不想和任何潜在的使用Ruby的客户工具冲突
Ruby对新手而言不够严格
和我一样对Ruby熟悉的话，由于Ruby的灵活性和元编程，查看别人的代码会极其困难。
我们团队考虑了以上所有选项，我们全部同意使用Python。我着手写了一个访问我们API的库。这给我们构建工具提供了基础，同时也作为一个新工具参考项目（如测试，项目结构，可执行脚本等等）。
事情进展的很顺利，直到最近一个客户的情况发生。为了显而易见的原因，我们努力精简依赖。有几个库让这件事变得如此顺利- requests, envoy。我们也喜欢使用 Fabric来封装一些东西。
然后，我们遇到一个状况，一个客户拒绝我们引入外部的包。因此，虽然我们可以“半死”大部分我们的工具，有些事情就是不能工作。追踪传递的依赖真是痛苦。
这就是导致我上面陈述的原因。
用Go构建工具Go，虽然不像Python那么容易调试，也还非常容易调试。编译速度很快，测试速度也相当快。但依赖问题才是真正的杀手锏。Go根本就不存在依赖问题。我可以把我编译好的二进制文件任意移动而不出任何问题，也不需要安装运行时。在标准库中也有很多有用的东西。
我也可以在osx，windows或者linux上不做任何更改的编译相同的代码。这也比我们使用Python方便。