回顾过去的一年，我们在技术栈上的最大改变就是从 Node.js 切换到 Go 。我们的联合创始人，Steve Kaliski， 在 Poptip 把 Node.js 切换成了 Go，可惜他没有学习到当时的教训。在用 Node.js 建立了 Bowery 的第一个迭代版本后，我们在2014年2月切换到了 Go，我们的开发和部署速度也因此得到提升。
从那以后，我们整个团队都变成了专职的地鼠（译者注：Go 的吉祥物）。Go 清晰明确的标准和更简便的工作流程让我们用 Go 用得很舒服。下面是我们热爱用 Go 进行工作的原因，你可以从中瞄一眼我们的地鼠洞。
容易编写跨平台代码
我们切换成 Go 的其中一个最大原因就是它是那么容易去为不同系统编译代码。
在 Bowery， 我们在建立一个能帮忙你和你的团队管理你们的开发环境的app，我们必须要高效地支持所有操作系统——Linux，Windows 还有 OSX。在Go中，你可以为不同的操作系统定义不同的文件，从而实现依赖于操作系统的功能。一个绝佳的例子就是我们的同伴 Larz 在构建一个从命令行读取用户输入的包 Prompt 的事。Larz 希望去创建一个 Go 包用来实现跨平台的行编辑提示。这在 Go 中是如此简单：为每个操作系统创建不同的文件，Go 编译器会根据操作系统来选择应使用的文件来生成最终内容。
为其他的系统编译代码同样很简单，你要做的仅仅是设置一个环境变量，然后你就有了一个你在 Linux 系统上编译的 Windows 二进制文件。
更快的部署
Go 是一款编译型语言并且可以更轻松地在多个平台上分发应用。 对我们而言，部署和测试是很重要的，同时也是我们最终用户的一个资产。通过 Go，构建服务然后运行测试会很容易，因为迁移到生产环境的服务器时就准备好了。 Go 不需要任何的系统依赖，让它的发布真的很简单。 当要发布命令行工具或者其它应用时，我们的用户不需要担心要安装Java,RVM或者NPM才能运行。 我们喜欢这篇Jeremy Saenz 的文章,他讨论了为什么他把他所有的命令行工具迁移到Go(CLI tools to Go)。
并发基元
当切换到Go时我们意识到Node.js的事件循环并不是一切。Node.js 没有提供太多的并发基元。唯一能同时运行的是I/O程序和定时器等。你无法通过这些程序通讯,所以用Node.js建立一个敏捷的系统是一个挑战。使用Go，你可以在运行任意并程序的同时，提供一个频道去给程序发送信号让它做一些事情，或者给它们发送一些值来共享数据。Go还提供了像 mutexes, wait groups等低级别的并发基元 。 有的你可能在NPM上找到，但我们发现在处理并发和并行时频道是决定性因素。
集成测试框架
用Node.js的时候，我们已经有了我们的测试框架选择，但一些框架对于前端来说更好用，比如Jasmine， 其它的框架则对后端来说更好用，比如Mocha。也有其它的选择像JSUnit和PhantomJS，如果你看过StackOverflow的这篇文章，那里也有人推荐许多的框架。在一些世界里，选择是一件好事，但使用Go的时候，我们喜欢测试框架的规范化。在Go里，所有的测试包都是内置的。如果你需要写一个新的测试套件，你必须做就是把(文件名)_test.go文件加到你要测试的软件的同一个包里,它将会在你每次执行go test的时候运行。
你可以在writing tests with Go学到更多关于Go 测试的知识。 需要测试HTTP services? Go同样提供了httptest包
标准库
我们喜欢仅用Go的标准库就能写大多数的软件。用Node.js时，我们几乎都是不得不引入一个外部的库, 这样做既增加了部署的时间，也增加了来自第三方软件的潜在隐患。只用标准库能让我们写的代码更快更安全。
开发者用的工作流工具更强大
Node.js除了NPM的包和脚本控件，没有真正的标准化的工作流。除此之外, 因为这些工具是社区创造的，虽然很好用但是实在太多了，以至于最终的结果就是事情被每个人以不同的方式完成了。在Go里工作流标准化的一个很好的例子就是工作区的布局。你要放弃很多开发自由因为你必须遵守工作区的布局，不过它提供了大量的结构：你可以保留你的Go源码和依赖在同一个位置。在你的工作区你有3个根目录： src 放源码包，pkg放编译过的包，bin放可执行的程序。让你的源码和依赖放在一个单独的工作区是一个最佳实践， 让它在每个人的机器上都是这个标准。在团队合作里这些可预测性是让人满意的。我们可以去任何人的机子上提供帮助，并且知道我们的代码将会出现在$GOPATH/src/github.com/Bowery这个路径，而不是其它像$HOME/some/path/to/Bowery这样的路径。类似的,gofmt用同样的方式格式化每个人的代码。对于一些肤浅的问题，像组织代码和代码风格差异在Go里根本不需要担心，这是一个大大的解放。你可以专注修复你的问题，其它的事都被考虑到了。