Why Go.?

Go(Golang) is something new for you. This article does not require any prior experience with the language.

We will go through following topics:

• GoDoc
• Static code analysis
• Built-in testing and profiling framework
• Race condition detection
• Learning curve
• Reflection

GoDoc

Documentation in code is taken very seriously in Go. So is simplicity.

GoDoc is a static code analyzing tool that creates beautiful documentation pages straight out of your code. A remarkable thing about GoDoc is that it doesn’t use any extra languages, like JavaDoc, PHPDoc, or JSDoc to annotate constructions in your code. Just English.

Static code analysis

Go heavily relies on static code analysis. godoc for documentation, gofmt for code formatting, golint for code style linting, and many others.

Those tools are commonly implemented as stand-alone command line applications and integrate easily with any coding environment.

Static code analysis isn’t actually something new to modern programming, but Go sort of brings it to the absolute. I can’t overestimate how much time it saved me. Also, it gives you a feeling of safety, as though someone is covering your back.

Built-in testing and profiling framework

Have you ever tried to pick a testing framework for a JavaScript project you are starting from scratch? If so, you might understand that struggle of going through such an analysis paralysis. You might have also realized that you were not using like 80% of the framework you have chosen.

Go comes with a built-in testing tool designed for simplicity and efficiency. It provides you the simplest API possible, and makes minimum assumptions. You can use it for different kinds of testing, profiling, and even to provide executable code examples.

It produces CI-friendly output out-of-box, and the usage is usually as easy as running go test. Of course, it also supports advanced features like running tests in parallel, marking them skipped, and many more.

Race condition detection

You might already know about Go-routines, which are used in Go to achieve concurrent code execution.

Concurrent programming in complex applications is never easy regardless of the specific technique, partly due to the possibility of race conditions.

Simply put, race conditions happen when several concurrent operations finish in an unpredictable order. It might lead to a huge number of bugs, which are particularly hard to chase down. Ever spent a day debugging an integration test which only worked in about 80% of executions? It probably was a race condition.

All that said, concurrent programming is taken very seriously in Go and, luckily, we have quite a powerful tool to hunt those race conditions down. It is fully integrated into Go’s tool chain.

You can read more about it and learn how to use it here: Introducing the Go Race Detector — The Go Blog.

Learning curve

You can learn ALL Go’s language features in one evening. I mean it. Of course, there are also the standard library, and the best practices in different, more specific areas. But two hours would totally be enough time to get you confidently writing a simple HTTP server, or a command-line app.

The project has marvelous documentation, and most of the advanced topics have already been covered on their blog: The Go Programming Language Blog.

Go is much easier to bring to your team than Java (and the family), JavaScript, Ruby, Python, or even PHP. The environment is easy to setup, and the investment your team needs to make is much smaller before they can complete your first production code.

Reflection

Code reflection is essentially an ability to sneak under the hood and access different kinds of meta-information about your language constructs, such as variables or functions.

Given that Go is a statically typed language, it’s exposed to a number of various limitations when it comes to more loosely typed abstract programming. Especially compared to languages like Javascript or Python.

Moreover, Go doesn’t implement a concept called Generics which makes it even more challenging to work with multiple types in an abstract way. Nevertheless, many people think it’s actually beneficial for the language because of the amount of complexity Generics bring along. And I totally agree.

According to Go’s philosophy (which is a separate topic itself), you should try hard to not over-engineer your solutions. And this also applies to dynamically-typed programming. Stick to static types as much as possible, and use interfaces when you know exactly what sort of types you’re dealing with. Interfaces are very powerful and ubiquitous in Go.

However, there are still cases in which you can’t possibly know what sort of data you are facing. A great example is JSON. You convert all the kinds of data back and forth in your applications. Strings, buffers, all sorts of numbers, nested structs and more.

In order to pull that off, you need a tool to examine all the data in run-time that acts differently depending on its type and structure. Reflection to rescue! Go has a first-class reflect package to enable your code to be as dynamic as it would be in a language like JavaScript.

An important caveat is to know what price you pay for using it — and only use it when there is no simpler way.

You can read more about it here: The Laws of Reflection — The Go Blog.

You can also read some real code from the JSON package sources here: src/encoding/json/encode.go — Source Code.

Few more topics to come-up.just follow.Thank you.