Go vs. Java: the beginning

This is the first post in the “Go vs. Java” miniseries in which I will show the differences between these two platforms. 

Why? This post is targeted at people who code and are eager to learn or migrate to Go. More advanced users won’t find here anything which isn’t covered in the official documentation. Nevertheless, I encourage you to give it a try and look at the subject matter from a different perspective.

In Java, where my roots are, there are plenty of tools that help developers simply do their job. With build tools such as Maven, Gradle or sbt, equipped with literally hundreds of plugins, I am capable of doing almost anything I could dream of. A huge community of developers makes it easy to choose the right tool to get the job done. However, everyone has their own preferred way of {testing|profiling|building} as there is a number of tools that help to achieve the same goal – writing efficient, secure and beautiful code.

Having lots of options is not particularly bad – as we know, competition results in better/cheaper goods for end-users and is a catalyst for innovation. Whether we talk about build tools, grocery shops or car manufacturers – the more goods and brands on the market, the better (exception: streaming services) for consumers. As simple as that. One might say that necessity is the mother of innovation but, that doesn’t change the point.

Anyway, a great variety of options could quickly become overwhelming as a developer, I have heard a number of discussions among Java devs about which formatting rules to use, which dependency manager to choose or which library for test assertions is better. The facts are that in the long run, most of these simple decisions don’t matter. As long as things stay consistent, we get used to it after some time (usually less than one week) we get used to it and life goes on. Don’t get me wrong; choosing the right tool for the job is still as important as being pragmatic and need-driven in crucial technical choices.

The point of view this post is intended to show is completely different from Java philosophy, according to which the community itself maintains most of the tools used for development. Because of that, it sometimes causes trouble with onboarding new team members, keeping the system up to date or satisfying license/security requirements. Go philosophy is quite different. To my mind, it’s important to know both approaches. Golang authors decided to save time of our developers, their supervisors, and team leads. (after all, someone has to settle the dispute and decide whether we use 2 or 4 spaces for indentation). They did us the courtesy of creating a language with an ecosystem that is opinionated.

The too-long introduction is over, let’s start with the proper content.

Today’s article focuses on a few basic concepts that stand as a core build blocks for most (technically at least) successful projects.

Formatting

Go comes with go fmt, which is considered by the community as the most user-friendly tool. It simply searches for files with Go’s source code and produces formatted output based on Go convention, which, of course, is an opinionated convention.

go fmt operates on files or folders by processing .go files. It can either format a file in place or print the formatted code to standard output in order to keep the source file untouched.

I won’t cover technical details such as how files are formatted, what command-line options are available but this and that link do a great job at explaining everything.

Technical details, such as the way in which files are formatted, or available command-line options won’t be covered here, but this and that link do a great job at explaining everything.

Java, however, does not have a built-in source code formatter. There are a couple of ways to keep code formatted: IDE, commit hooks or code review, to name a few. Just that alone gives a lot to choose from and we haven’t even started considering TABs or spaces yet!

Both approaches give us similar results. After all, the source code is formatted, but Go authors decided to create one source of truth for all developers, by making formatting conventions standardized, which is not common in other ecosystems.

I find Go’s way super useful and unusual. I just like it when, for such noncritical matters, a tool decides for me and doesn’t leave any room for argument. And oh boy, I have met some people that can spend hours and hours discussing such things.

Testing

Another opinionated area where Golang shines: it comes with built-in support for tests.

The go test is super easy to use as it discovers tests methods that fulfill those really simple requirements:

  • name of the method matches TestXxx (where “Xxx” is any string)
  • contains *testing.T as the first and the only argument
  • sits in files with _test.go suffix

As simple as that! No need to configure Maven plugins, choose a testing framework or debugging when my tests aren’t starting. 

“testing.T” provides us with some utilities such as assertions, parallel test executors and more. Although this is “the only” way of writing tests in Go, more experienced developers might need more flexibility – frameworks like Spock or Junit are best in class for this kind of job while still providing support for many third-party integrations. On the other hand, there are a plethora of testing libs for Golang that simply wrap standard, build-in convention.
Another advantage of the standardized tool is that new developers that have just joined the project might go through the ramp-up period very, very quickly as this is a built-in construct. Being, so to say, forced to use build-in constructs is one of key reasons why Golang exists and why it is so simple to use it in the long run.

Dependency management

Aaaaand finally, one of the hottest topics in the Go world (generics are next in line).

For the last couple of years a few ways of managing dependencies in Golang have been invented, but that topic is changing rapidly.

Historically, Go came with go get tool whose single responsibility was to fetch dependencies. It was so simple and sometimes even limited, so people started creating their own dependency managers with proper version management, vendoring and locks. There were numerous issues with the early versions of “go get”, for example, its relationship with the single global GOPATH(i.e. the place on where all Go code resides), no proxy/caching option or the impossibility of pointing to the specific version of code that needs to be fetched.

Unofficial tools like glide and Govendor, just to name a few, began to conquer the market. In the meantime, the official tool was under development – https://github.com/golang/dep, which was said to be an “official experiment”. Its development became the basis for the creation of something called go mod. It’s actually a very oversimplified description of what was happening as the whole process took several years. go mod is a tool similar to other dependency management tools; it supports semantic versioning, lock files, custom repositories and more. Similar to Gradle or Maven (which aren’t just dependency managers), it helps us create better software by offloading lots of important tasks and decisions.

That being said, I think that with long awaiting, built-in dependency manager with core features mentioned above, Golang finally has become a first-class language.

Final words

That was a deliberately oversimplified description of what is happening in the Go world, but I hope that you get my point. Key takeaways are that Golang comes with build-in tools for key development areas which actually work, without scripting, installing third-party binaries or worrying about compatibility and licensing issues.
The design decision mentioned above doesn’t come without cost and this post is not supposed to answer the question which language is better. When I switched to Golang from Java, I was sometimes shocked how easy things could be! Among Java developers there are people whose hobby is apparently – waging religious wars about things described above. Golang, on the other hand, leaves very little room for complaints – you either like it or not. Maybe that’s what makes it so attractive, who knows!

2 thoughts on “Go vs. Java: the beginning”

  1. There should be links in formatting section but they were not processed/added.

Leave a Reply