Go语言之于系统管理员

“就算我从来没有直接接触过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方便。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.heiqu.com/956b144c0967e2a26ac53398add79b1d.html