My thoughts: nice things in Go Lang, which aren’t in Java

I recently published my first project witch was written in Go language: loga. After that I have some insights about some Go futures that haven’t Java. Of course it’s my subjective opinion, so I invite you to discussion in comments.

At first, the nice things for me

1. Import sources directly from

We can import library from as simply as we have it locally:

import (

2. Built-in tool for formatting code

We only must use command:

go fmt yourprojct

Of course we have many tools for formatting code in Java, but in this case that can be disadvantage. If some programmer will be use different tool to formatting code that other programmer, then will be ping-pong in the code. Sometimes less is better 😉

3. Checking if imports are uses

Exactly! When we add some import and not use it, then we get compilation error:

dmarciniak@laptop:~/Projects/go$ go build loge
src/loge/logEntry.go:5:2: imported and not used: "os"

Goroutines & channels

Combination of goroutines and channels is very useful for concurrency programming. In Go you can every function run asynchronously by adding go statemet before this execution:

go doSth(arg1, arg2)

It’s very simple!

Additionally to communicate between asynchronous functions you can use channels. Chan is built-in type to sending and receiving data:

package main

import "fmt"

func f(c chan int, val int) {
	c <- val * 10

func main() {
	c := make(chan int)
	go f(c, 1)
	go f(c, 2)
	go f(c, 3)
	fmt.Println(<-c, <-c, <-c)

Above code return values 10, 20, 30 in random order.

In loge project I use channels to asynchronously loading lines with logs from many logs files.

Now, not so good things in Go (in my opinion)

1. Returns many values

val1, val2 := func()

Although, sometimes that gramar can be useful it also make code less readable. In Java we can use DTO object to return more than one value, and name of type of this (returned) object can be descriptive.

2. No exceptions

We don’t have exceptions in Go. The common practice is returning error type as the next value and checking this type in the next step. That construction increases amount of lines in code. Below comparison of code in Go and Java. For me, code in Java is more neat.


func logsEvents(g *gocui.Gui) error {
	if err := g.SetKeybinding(viewLogs, gocui.KeyArrowUp, gocui.ModNone, scrollUpLogs); err != nil {
		return err
	if err := g.SetKeybinding(viewLogs, gocui.KeyArrowDown, gocui.ModNone, scrollDownLogs); err != nil {
		return err
	if err := g.SetKeybinding(viewLogs, gocui.KeyArrowLeft, gocui.ModNone, scrollLeftLogs); err != nil {
		return err
	if err := g.SetKeybinding(viewLogs, gocui.KeyArrowRight, gocui.ModNone, scrollRightLogs); err != nil {
		return err
	if err := g.SetKeybinding(viewLogs, gocui.KeyPgdn, gocui.ModNone, scrollPgdnLogs); err != nil {
		return err
	if err := g.SetKeybinding(viewLogs, gocui.KeyPgup, gocui.ModNone, scrollPgupLogs); err != nil {
		return err
	if err := g.SetKeybinding(viewLogs, gocui.KeyEnter, gocui.ModNone, openFileLogWindow); err != nil {
		return err
	if err := g.SetKeybinding(viewLogs, gocui.KeyCtrlN, gocui.ModNone, loadNextLogs); err != nil {
		return err

	return logsPopupEvents(g)


void logsEvents(Gui g) throws SetKeybindingExceptoin {
		g.setKeybinding(viewLogs, Gocui.KEY_ARROW_UP, Gocui.MOD_NONE, scrollUpLogs);
		g.setKeybinding(viewLogs, Gocui.KEY_ARROW_DOWN, Gocui.MOD_NONE, scrollDownLogs);
		g.setKeybinding(viewLogs, Gocui.KEY_ARROW_LEFT, Gocui.MOD_NONE, scrollLeftLogs);
		g.setKeybinding(viewLogs, Gocui.KEY_ARROW_RIGHT, Gocui.MOD_NONE, scrollRightLogs);
		g.setKeybinding(viewLogs, Gocui.KEY_PGDN, Gocui.MOD_NONE, scrollPgdnLogs);
		g.setKeybinding(viewLogs, Gocui.KEY_PGUP, Gocui.MOD_NONE, scrollPgupLogs);
		g.setKeybinding(viewLogs, Gocui.KEY_ENTER, Gocui.MOD_NONE, openFileLogWindow);
		g.setKeybinding(viewLogs, Gocui.KEY_CTRL_N, Gocui.MOD_NONE, loadNextLogs);

3. Files with code and tests in this same path

In Go, tests was created by creating file with “_test” postfix in name, so files with code and tests share that same path. It may interfere in big projects.


I had a lot of fun with learning Go. I think that this language have a lot of fantastic future, which we frequently have to added by external libraries and tools in Java. Nonetheless I still prefer use Java to big commercial projects, and I sometimes will be come back to Go in small private projects (just for fun).