Golang for Java-Coders

The mocking gopher: a fitting mascot for golang

I want to share my experiences when I started programming in Golang from my perspective as a Java Coder.

What is this and why???

So first I wanted to know what is Golang. Rumors from my colleagues put it into one class with C and C++ (which it is not), this is not true at all. Golang is not a low-level language, it is far closer to Java than to C (from an abstraction perspective). These rumors probably come from the fact that it has a small amount of keywords and control structures reminding a bit of C.

When you read or listen to the talk the creators of the language gave at google, you get a much better idea of what it is and what problems it is supposed to solve. Basically they wanted a language for their C + C++ coders which is safer and easier and which compiles faster and which was built with concurrency in mind.

“Go at Google: Language Design in the Service of Software Engineering” Rob Pike, Google, Inc.

(Video) https://www.infoq.com/presentations/Go-Google
(Transcript) https://talks.golang.org/2012/splash.article

Reading/watching this helped me to understand a lot better what the intentions behind golang were.

Down the rabbit hole

Golang ships with a lot of nice basic stuff builtin, but for medium sized projects you need more.

Dependency Management (like maven)

Golang has its build and dependency management tool builtin. You don’t need any external tool. Unfortunately the golang dependency management does not use some versioning system. Instead you point your program to the github (or other website) master branches of other repos. Yes, I am not kidding. Again this makes more sense if you see it from googles perspective where they run all their stuff in a big repo. Probably they prefer breaking stuff as they are able to fix it right away.

There are workarounds like gopkg.in or vendoring (including the other source in your repo in a vendor folder). We used the “govendor” command in one of our projects.


Read more here:



Golang has very basic logging builtin, but doesn’t cover loglevels, etc. as a java coder you want something like e.g.:


There are a lot more golang logging libraries out there, just search for them if you want.


Golang has basic testing builtin, but for nicer assertions, etc. you might want to use helperfunctions from e.g. testify.


Again, there are a lot more testing frameworks out there.


Mocking in golang is a bit messy, there are some libraries with generators, but I am missing mockito. For now mostly I just built my own mock structs which implement the interface I want to mock.

Update: After digging a bit deeper it is actually possible to generate the needed mock structs quite conveniently using mockery and go generate.


Now you can add the generate expressions over the interfaces for which you need the mocks. This will generate a mock in a subpackage mocks:

//go:generate $GOPATH/bin/mockery -name MyInterface
type MyInterface interface {
 DoSomething() string

Then run go generate.

$> go generate your_module...

Now in your test you can similarly to Mockito mock functions, e.g.

myMock := &mocks.MyInterface{}
myMock.On("DoSomething").Return("It works!")

Best golang book for Java Coders

The bare minimum you need to program in go. Exactly what you need, not more not less. A quick introduction into the golang programming language for experienced programmers.



Resumé after 6 months of Golang, the Good, the Bad, the Ugly

Google developed golang to fullfill very specific needs

  • compile speed. Golang has to compile very fast enormous amounts of code
  • all your code: Google mostly uses its own libraries. If they need a change they do it in all dependent projects, if they break something they fix it in all projects. This is a closed ecosystem. They can just pull the master of a repo and be happy with it
  • dumb language: Google intentionally built a language which is dumbed down to a minimum of features to meet their compile speed goal and to have as unfancy and obvious code as possible at the cost of a much greater verbosity. Googles motto is don’t refactor, rewrite.
  • Easy threadsafe parallelism (on the same host, NOT network) by implementing a kind of actor model (go functions, channels)

Interestingly most of these needs are usually not present for most companies

  • I never worked for a company who had any real world issue with compile speeds or where this was influencing a technology decision
  • Most software I wrote used a lot of external dependencies not under my control. I definitively want a package manager which can deal with versions without hacks like vendoring or gopkg.in.
  • Imho the biggest pain point with go: it is a really really dumb language. This leads to easy to read small programs and horrible to read and verbose bigger programs. I can acknowledge that there might be a usecase for having a language with reduced features, but I definitively don’t want to work with it. More to that point later.
  • Easy threadsafe parallelism comes in handy when you need it, but this is a very narrow specific usecase: small programs with high needs of parallelism and performance. Usually small servers with a specific narrow usecase.

Annoying language phenomens

As a Java developer the go world is awfully verbose. After 6 months these are my pain points (biggest pain first):

  • Explicit Error handling. While this might be ok if you write small servers for any growing golang program this quickly explodes into an orgy of if err!=nil { return err } . You get to a point where you just want to smash the keyboard against the monitor if you have to write another one of these if elses. I prefer try-catch (Java, Python) a lot compared to this madness.
    Rust eases this problem by having some shortcuts (?) https://m4rw3r.github.io/rust-questionmark-operator . Golang offers nothing to ease your pain.
  • No collection standard functions. How often I longed for a contains, map, filter. Instead well “why should we add it, you can just write a for loop very quickly” <- I hate you golang
  • No dependency injection frameworks. Welcome to good old handcrafted constructor DI. A big factory wiring together all the shit in the right order. You will miss Spring DI
  • Interfaces: Golang has duck-type style interfaces, which means the interface doesn’t have any dependency to the implementing struct but it also means you simply don’t know which structs do implement an interface. Personally I don’t like this too much as for me the advantage of sparse interfaces is negated by the overall confusion it causes in bigger codebases.
  • Crosscutting concerns are usually implemented painfully. We added swagger to our software and had to rewrite the routing so the swagger library creates the http Handler. Everything feels so unnecessary complicated in golang.
  • No Generics (well just google if you want to know more)

TLDR; If you don’t know exactly why you want golang don’t use golang

Of course this all is my very own personal opinion. If you disagree I would be glad to hear your story in the comments.


pixelstats trackingpixel

Leave a comment

Your comment

Time limit is exhausted. Please reload the CAPTCHA.