Go is without a doubt a growing language. Some still consider it a young language, due to the fact that it was released “just” under 5 years ago. Regardless of this, Go has seen a good adoption in the servers and networking space, with projects like Kubernetes, Terraform, rkt or Docker all being written in Go.

Now, you see all those cool projects, you hear that Go has an excellent performance, it’s easy to read, fun to write and you’ll say: I want to use this on my job. How should I get my colleagues / boss to accept it as well?

First of all, let me stop you from your first impulse. Whatever you want to do, do not force Go upon your colleagues / company. If you do that, chances are that it will be met with more resistance than you expect and most likely you’ll fail to get anywhere with it. And that’s the best case scenario.

Another important aspect to consider would be how proficient are you with it. The more proficient you are, the easier it will be to argue for Go as you’ll be able to inspire confidence to your colleagues on your knowledge about the language. This will be useful as introducing a new language always comes with risks and potential problems that you might not anticipate from the beginning.

There are different approaches to this so I’ll talk a bit from the experience I’ve had introducing it to three different companies.

By far, the most effective is the one where you are lucky and your peers will already be interested in a new language, maybe even Go itself. If you are in this situation then most of the work is done. A key factor in this case is having a fair comparison with either other languages that are being investigated.

The next, more common situation, will be that you are the only one in the team, or maybe even the whole company, that knows anything about Go.

What worked great for me was to do small tools which solve specific problems, preferably that do not impact the business but do make your life or others a lot easier.

Another approach is writing a small piece of your system, preferably something quick to refactor but that could gain a lot from Go’s strengths: either the code will be a lot easier to read, to maintain or a lot faster.

Naturally, if you do these small things, at some point your colleagues might wonder about them and then you can have a discussion about the language. Then you’ll be able to show the strengths and weaknesses of Go.

At the end of the day you might have either success with this or not, you have to keep in mind that people should choose their tools to fit the problem space they are working on but they’ll also pick something they “like”. And sometimes it’s worth waiting for a few months and gauging the interest again.

Don’t sugar coat Go, don’t try to make it the silver bullet your team needs and most of all, not force upon others and don’t forget that there are a lot of open-source projects that need your help. So if you are unsuccessful in getting your company to use it, you can still work with Go on various fun projects until such time this decision will be revisited.