Switch from Node.js to Go platform

After building the first iteration of Bowery with Node.js, we switched to Go in February 2014, which increased our development and deployment speed.

Since then, our entire team has become dedicated ground squirrels. Go's clear standards and easier workflow make it easy to use Go. Here's why we love working with Go, and you can peek into our gopher hole.

Easy to write cross-platform code

One of the biggest reasons we switched to Go was that it was so easy to compile code for different systems.

At Bowery, we're building an app that helps you and your team manage your development environment, and we have to support all operating systems efficiently -- Linux, Windows, OSX. In Go, you can define different files for different operating systems to implement functions that depend on the operating system. A great example is our companion Larz building a package Prompt that reads user input from the command line. Larz wants to create an Go package to implement cross-platform line editing prompts. This is so simple in Go: create a different file for each operating system, and the Go compiler will select the file to use based on the operating system to generate the final content.

Compiling code for other systems is also simple. All you have to do is set an environment variable, and you have an Windows base 2 file that you have compiled on an Linux system.

Faster deployment

Go is a compiled language that makes it easier to distribute applications across multiple platforms. For us, deployment and testing are important and an asset to our end users. With Go, it is easy to build the service and then run the tests, because you will be ready when you migrate to the production server. Go doesn't require any system dependencies, making it really easy to release. Our users don't need to worry about installing Java,RVM, or NPM to run when publishing command-line tools or other applications. We liked this article on Jeremy Saenz, which discusses why he migrated all of his command-line tools to Go(CLI tools to Go).

Concurrent primitives
When we switch to Go we realize that the Node.js event loop is not a one-cut. Node.js does not provide many concurrent primitives. The only ones that can run at the same time are the I/O programs and timers. You can't communicate through these programs, so building an agile system with Node.js is a challenge. With Go, you can run any parallel application while providing a channel to signal the application to do something, or to send them a value to share data. Go also provides low-level concurrent primitives such as mutexes, wait groups, and so on. Some you might find on NPM, but we found that channels are the deciding factor when dealing with concurrency and parallelism.

Integration testing framework

With Node.js, we have our choice of testing frameworks, but some are better for the front end, such as Jasmine, and others are better for the back end, such as Mocha. There are other options like JSUnit and PhantomJS, and if you've seen this article on StackOverflow, there are a lot of frameworks that are recommended. In some worlds, choice is a good thing, but with Go, we like to test the normalization of the framework. In Go, all test packages are built in. If you need to write a new test suite, you must add the file _test.go to the same package as the software you are testing. It will run every time you execute go test.
You can learn more about the Go test at writing tests with Go. You need to test. Go also offers the httptest package

The standard library

We like to be able to write most software using Go's standard library alone. With Node.js, we almost always have to introduce an external library, which increases both deployment time and potential vulnerabilities from third-party software. Using only the standard libraries allows us to write code faster and more secure.

Developers use more powerful workflow tools

Node.js there is no really standardized workflow except for NPM's package and script controls. In addition, because these tools were created by the community, they were great to use but so many that the end result was that things were done differently by everyone. A good example of workflow standardization in Go is workspace layout. You have to give up a lot of development freedom because you have to follow the layout of the workspace, but it provides a lot of structure: you can keep your Go source code and dependencies in the same place. You have three root directories in your workspace: src for source packages, pkg for compiled packages, and bin for executable programs. It is a best practice to have your source code and dependencies in a separate workspace, and make it the standard on everyone's machine. In teamwork, this predictability is satisfying. We can offer help to anyone's computer, and know that our code will appear in the $GOPATH/src/github com/Bowery this path, rather than other like $HOME/some/path to/Bowery such a path. Similarly,gofmt formats everyone's code in the same way. For some superficial problems, such as organizing code and code style differences, there is no need to worry at all in Go, which is a great liberation. You can focus on fixing your problems and everything else will be taken into account.

There are a number of other reasons to like Go. We are seeing more and more companies adopting Go to make their internal applications more powerful and distributed. But overall, the Go team has found that developers are more productive if you create standards and make examples that others agree to. For example, MongoDB's application management team likes to use Go's "smart, consistent development experience." At Soundcloud, they like to use Go's strict formatting code rules and "there's only one way to do it" philosophy. This means you spend less time reviewing code and arguing about code style and format, and more time addressing the root cause of your problem.

If you're new to Go and want to learn more, here are some resources to check out.

Read updates to the Golang official blog and announcements from the core team
Read the learning documentation provided by the core team on the official website
We love Bill Kennedy studio's Bill Kennedy tips and guides on Going Go Programming blog
Go by Example has a bunch of examples of different tasks written in Go
GopherAcademy has many articles on best practices for Go
A good article for Brian McCallister is the Go workspace and overall development environment
For more on the code organization of Go, read the article Jared Carroll published in Pivotal Labs blog
If you're starting your first Go project, set up your new environment and share it with your team at Bowery.

Please take a moment to share this article with your friends or leave a comment. We will sincerely appreciate your support!