After we built the first iteration version of Bowery with Node.js, we switched to go in February 2014, and our development and deployment speed improved.
Since then, our entire team has become a full-time hamster (the go mascot). Go clearly defined standards and simpler workflows let's take it very well. Here's why we love to work with go, and you can take a peek at our gopher hole.
Easy to write cross-platform code
One of the biggest reasons we switch to go is that it's so easy to compile code for different systems.
In Bowery, we are building an app that will help you and your team manage your development environment, and we have to effectively support all operating systems--linux,windows and OS X. In go, you can define different files for different operating systems to achieve the functionality that depends on the operating system. An excellent example of this is our companion Larz building a package Prompt from the command line to read user input. Larz wants to create a go package to implement a cross-platform line editing hint. This is so simple in go: To create a different file for each operating system, the goes compiler chooses the file that should be used to generate the final content based on the operating system.
Compiling code for other systems is also very simple, and all you have to do is set up an environment variable, and then you have a Windows binaries that you compile on a Linux system.
Faster deployment
Go is a compiled language and makes it easier to distribute applications across multiple platforms. For us, deployment and testing are important, as well as an asset to our end users. With go, it is easy to build a service and then run tests, because you are ready to migrate to a server in your production environment. Go doesn't need any system dependencies, so it's really easy to publish. When it comes to publishing command-line tools or other applications, our users don't have to worry about installing JAVA,RVM or NPM to run them. We loved this article Jeremy Saenz, and he discussed why he migrated all his command-line tools to the Go (CLI tools).
Concurrent Primitives
When we switch to go, we realize that Node.js's event loop is not everything. Node.js does not provide too many concurrent primitives. The only thing that can run at the same time is 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 and all programs at the same time, provide a channel to send a signal to the program to do something, or send them some value to share data. Go also provides low-level concurrency primitives like mutexes, wait groups. Some of you may have found it on NPM, but we found that the channel was the deciding factor in dealing with concurrency and parallelism.
Integrated test Framework
With Node.js, we already have our test framework choices, but some frameworks are better for the front end, such as Jasmine, and other frameworks are better for the backend, such as Mocha. There are other options like Jsunit and Phantomjs, and if you've seen this article in StackOverflow, there are also a number of frames that are recommended. In some worlds, choice is a good thing, but when you use go, we like the normalization of the test framework. In go, all the test packages are built in. If you need to write a new test suite, you have to do is add the (filename) _test.go file to the same package as the software you want to test, and it will run every time you execute go test.
You can learn more about go testing in writing tests with went. Need to test HTTP services? Go also provides a httptest package
Standard library
We like to write most of the software just by going to the standard library. When using Node.js, we almost all had to introduce an external library, which increased the time for deployment and added potential pitfalls from Third-party software. Using only standard libraries makes the code we write faster and more secure.
The workflow tools used by developers are more powerful
Node.js In addition to NPM's package and scripting controls, there is no real standardized workflow. In addition, because these tools are created by the community, although it is very useful but too much, so that the end result is that each person in a different way to do things. A good example of workflow standardization in Go is the layout of the workspace. You have to give up a lot of development freedom because you have to follow the layout of your workspace, but it provides a lot of structure: You can keep your go source and rely on the same location. In your workspace you have 3 root directory: src source Pack, Pkg put the compiled package, bin put executable program. Keeping your source code and dependencies in a single workspace is a best practice, making it the standard on everyone's machine. The predictability of teamwork is satisfying. We can help on anyone's machine and know that our code will appear in the path of $gopath/src/github.com/bowery, rather than other paths like $home/some/path/to/bowery. Similarly, gofmt formats everyone's code in the same way. For some superficial issues, such as organizational code and code style differences do not need to worry at all on the go, this is a big liberation. You can focus on fixing your problems, and everything else is taken into consideration.
There's a whole bunch of other reasons to like go, and we see more and more companies using go to make internal apps more powerful and distributed. But overall, the go team found that if you create standards and make examples that allow others to agree, developers will be more productive. For example, MongoDB's application management team likes to use Go's "smart, unified development experience." In SoundCloud, they like to use go to the strict formatting code rules and "the way to achieve only one" philosophy. This means that you spend very little time on code review and argument code style and format, and you can use more time to solve the root cause of your problem.
If you've just started using go and want to learn more, here are some resources to look at.
Read the update of Golang official blog and the announcement of the core team
Read the core team to provide a learning document on the website
We like the tips and guidelines for Bill Kennedy in Ardan's studio on the blog going Go programming
Go by Example has a bunch of examples of different tasks written with Go
Gopheracademy has a lot of articles about go best practices
Brian McCallister has a very good article on the Go workspace and the overall development environment
More about Go Code organization, read Jared Carroll posted in Pivotal Labs Blog article
If you want to start your first go project, set up your new environment and share it with your team in Bowery.
Please take a moment to share the article with your friends or leave a comment. We will sincerely thank you for your support!