Go good parts (Part 1)

1 min readFeb 4, 2021

I wrote a bit biting opinion about Go here, but there are definitely good parts in the language. They don’t change overall judgment, but I think they are worth mentioning.

Golang is designed to be pragmatic. Here is a feature I liked, not very theoretical one, but making coding more pleasant in most cases.

type Dog struct {
  counter int
  *log.Logger // <-- no name for field
  sync.Mutex  // <-- no name for field
}func Dog() S(string name) {
  return S{
    counter: 0,
    Logger: log.New(log.Writer(), name, log.Flags()),
    // mutex is default initiated to unlocked state
 }
}// some synchronized method on Dog
func (d *Dog) bark() {
  s.Lock() // calls Lock() on __the__ dog's mutex
  defer s.Unlock()
  ...
  s.Print(...) // calls Print() on __the__ dog's logger
}

If you don’t name field, you can still refer to it by type (d.Logger , d.Mutex). You can call methods on field as if they were implemented on your struct and delegated to that unnamed field (d.Panicf(...)).

I don’t expect you will run into situation when you would need e.g. two loggers or two locks for struct instance, so even if the use case has its limitations, you won’t usually run into any issues (I expect).

IMO a nice example how Golang tries to make everyday programming more pleasant.

Go good parts (Part 1)

Written by Marek Scholle