Why Tech Startups Should Look At Go II

William Kennedy talks in this article about the many technology benefits of Go in the startup ecosystem.

Yes, Go is important for your technology stack. If you grow big enough, in fact, you can save a lot of money on servers. But the article leaves out the massive flexibility benefits that Go brings to your codebase.

If you’re trying to find a market fit for your product, your code & technology will grow and change fast. Every once in a while you’ll get blindsided and have to change completely.

Hell, even if you’re established you’re gonna have to change. That’s just the nature of software.

Whatever/whoever you are, your product will change. And since your product is code, the transitive property applies here. If you can’t deal with a lot of code changing constantly, you’re done.

Here’s how Go helps you grow and change fast.

Simple Packages #

Creating a package is just putting files in a folder and writing

package mypackage

at the top of each file. You can write Go code as a monolith and split stuff out later if you want.

I’ve had to read pages on how to create & release packages for other languages. I’m disgruntled and bitter now and want to ditch those languages altogether for their transgressions. Because Go.

Simple Package Management #

You don’t have to learn a build/release tool (e.g. SBT, Maven, NPM, RubyGems), write build scripts or push to a central repository.

Just put your code on Github and

go get

it. You can use your new library from anywhere.

Note that this isn’t the whole story for Go’s package management. There are lots of tools and corresponding debates out there, but this is how everyone starts. And it took me a pretty long way.

Compiled #

I’ve seen Python and Ruby programs that have unit tests just to check the types of variables.

Go is statically typed and compiled, so those tests disappear. That’s a boost for your motivation and honestly you’ll feel like a better human being too.

And if you do like writing tests, you’ll spend more time testing, you know, actual functionality.

Plus, you get some more fancy checks for free:

• cyclic package dependencies
• shadow variables
• unused packages
• unused variables
• booleans in if, for, etc…

Static Typing #

I mentioned types in the previous section. In Go, you declare a type when you assign a value to a variable. You can’t change the type unless you really mean to.

And Go has type inference. Instead of int i = 0, write i := 0 and the compiler still knows that i is an int. Go’s type inference is good. Your face will look like this when you have to go back to languages that don’t have it:

Naming & Scope #

Go takes this concept from predecessors. If any name starts with an uppercase character it’s public. Otherwise it’s private. You just save a ton of typing and memorizing. And no more access modifiers.

Static Analysis #

go fmt, go vet, golint are great static analysis tools that ship with go.

They do the following (in order):

• end all style & formatting wars
• check for stuff you often fuck up (e.g. concurrency)
• tell you to write more docs and other good stuff

The Go language is so easy to parse that new tools are always coming out, so there are definitely new static analyzers coming.

Documentation #

No special documentation syntax. Just write english, in a comment, above your function/variable/constant. The tools do the rest:

• run godoc to see docs for all go code (including yours) on your machine.
• push to a public Github repo (other less cool repos work too) and it’s automatically generated and indexed by godoc.org for free

No more publishing docs. One less thing to remember.

Testing #

There is ONE testing system that has a few rules. Follow them and it just works. No test runners or reporters to customize.

If you want you can choose from the many testing utilities and frameworks built on top of the basic system.

It’s less hard to get people to write tests in Go because it’s easy to set them up and the stdlib has good support for stubs/mocks where appropriate.

Code Coverage #

Go ships with good, visual code coverage. You just get it with the install, there’s no setup. Coverage is always good in any language but nobody wants to do it. Because there are usually a million roadblocks to set it up. It’s hard enough to get people to write tests.

There’s even a free service that runs coverage for you in the cloud.

Race Detection #

Run

go test -race

and it’ll report race conditions. Just like with code coverage, there’s no setup. Companies charge money to use their race detection tools for other languages.

Build Times #

Go was originally designed to scale to very large codebases. The original team designed everything so you could build large projects quickly. Rob Pike (one of the creators) did a keynote at SPASH 2012 that has tons of awesome details on how it works (and other awesome Go stuff). Read that when you can.

Basically, every minute you have to wait for the build is terrible. You’re wasting your life and most of the time waiting to run your tests.

And by the way, you’re not gonna run your tests again if they fail the first time. You’ve been down that road and you’re just not. Long build times train us to ignore tests.

Orthogonality, Part 1 #

There’s one more (huge) concept that Go has to offer your codebase: orthogonality. This term is one of my favorites.

There’s always the Wikipedia definition if you want to know exactly what this means.

But here’s what it means in practice, with Go:

• you will be building programs with a small toolbox
• each tool is simple, quality and easy to use
• you only need to use a few tools to get a really useful program
• most importantly for a big codebase, the tools don’t get in the way of each other

Conclusion #

I’m gonna write more about orthogonality in a later post. Meanwhile, write a few programs with Go (you don’t even have to install anything). And while you’re writing, think about the things you don’t have to do with Go compared to another language.

That’s why you should use Go for your startup.