The Go Language Controversial

Published Date: 02 Nov 2017

Introduction:

Samuel Tesla says that Go is not meant to innovate programming theory. It’s meant to innovate programming practice.

Go OOD(Object Oriented Design)

Google language Go is completely an object oriented language. Like other languages Go allows methods on any type one defines without all the boxing/unboxing. Go provides many same features as other programming languages but it does not use classes.It provides automatic message delegation via embedding, polymorphism via interfaces, name spacing via exports.

Composition

Go use object oriented design in terms of composition instead of inheritance so there is no relationship between classes.

Sandi Metz says that it is optional to use classic inheritance because any problem which it solves can be solved in any other way.

Composition by Example

Having recently read through Practical Object-Oriented Programming in Ruby, I decided to translate the examples to Go.

Chapter 6 presents a simple problem. A mechanic needs to know which spare parts to bring on a bike trip, depending on which bikes have been rented. The problem can be solved using classical inheritance, where MountainBike and RoadBike are specializations of a Bicycle base class. Chapter 8 reworks the same example to use composition instead. I'm quite happy with how well this versiontranslated to Go. Let's take a look.

Packages

package main

import "fmt"

Packages provide a namespace. The main() function of the main package is where a program begins. The fmt package provides string formatting functions.

Types

type Part struct {

Name string

Description string

NeedsSpare bool

}

We define a new type named Part. This structure is very much like a C struct.

type Parts []Part

The Parts type is a slice of Part objects. Slices are dynamically resizable arrays, and are quite common in Go.

We can declare methods on any type, so we don't need to wrap []Part in a struct. This means Parts can have all the behavior of slices, plus our own custom behavior.

Methods

func (parts Parts) Spares() (spares Parts) {

for _, part := range parts {

if part.NeedsSpare {

spares = append(spares, part)

}

}

return spares

}

A method declaration in Go is just like a function, except it has an explicit receiver, declared immediately after func. This function takes advantage of named return variables, pre-initializing spares for us.

The method body is fairly straightforward. We iterate over parts, ignoring the index position (_), filtering the parts to return. The append builtin may need to allocate and return a larger slice, as we didn't preallocate its capacity.

This code isn't nearly as elegant as select in Ruby. A functional filter is possible in Go, it just isn't builtin.

Embedding

type Bicycle struct {

Size string

Parts

}

Bicycle is composed of a Size and Parts. By not specifying a named field for Parts, we make use of embedding. This provides automatic delegation with no further ceremony, eg. bike.Spares() and bike.Parts.Spares() are equivalent.

If we were to add a Spares() method to Bicycle, it would take precedence, but we could still reference the embedded Parts.Spares(). This feels almost like inheritance, but embedding does not provide polymorphism. The receiver for methods on Parts will always be of type Parts, even when delegated through Bicycle.

Patterns used with classical inheritance, like the template method pattern, aren't suitable for embedding. It's far better to think in terms of composition & delegation, as we have here.

Composite Literals

var (

RoadBikeParts = Parts{

{"chain", "10-speed", true},

{"tire_size", "23", true},

{"tape_color", "red", true},

}

MountainBikeParts = Parts{

{"chain", "10-speed", true},

{"tire_size", "2.1", true},

{"front_shock", "Manitou", false},

{"rear_shock", "Fox", true},

}

RecumbentBikeParts = Parts{

{"chain", "9-speed", true},

{"tire_size", "28", true},

{"flag", "tall and orange", true},

}

)

Go provides a nice syntax for initializing objects, called composite literals. Being able to initialize a struct with an array-like syntax made the PartsFactory from the Ruby example feel unnecessary.

func main() {

roadBike := Bicycle{Size: "L", Parts: RoadBikeParts}

mountainBike := Bicycle{Size: "L", Parts: MountainBikeParts}

recumbentBike := Bicycle{Size: "L", Parts: RecumbentBikeParts}

Composite literals can also use a field: value syntax, in which all fields are optional.

The short declaration operator (:=) uses type inference to initialize roadBike, etc. with the Bicycle type.

Output

fmt.Println(roadBike.Spares())

fmt.Println(mountainBike.Spares())

fmt.Println(recumbentBike.Spares())

We print the the result of calling Spares in the default format:

[{chain 10-speed true} {tire_size 23 true} {tape_color red true}]

[{chain 10-speed true} {tire_size 2.1 true} {rear_shock Fox true}]

[{chain 9-speed true} {tire_size 28 true} {flag tall and orange true}]

Combining Parts

comboParts := Parts{}

comboParts = append(comboParts, mountainBike.Parts...)

comboParts = append(comboParts, roadBike.Parts...)

comboParts = append(comboParts, recumbentBike.Parts...)

fmt.Println(len(comboParts), comboParts[9:])

fmt.Println(comboParts.Spares())

}

Parts behaves like a slice. Getting the length, taking a slice, or combining multiple slices all works as usual. The equivalent solution in Ruby is to subclass Array, but unfortunately Ruby "misplaces" the spares method when two Parts are concatenated.

"…in a perfect object-oriented language this solution would be exactly correct. Unfortunately, the Ruby language has not quite achieved perfection…" - Sandi Metz

There is a somewhat ugly workaround in Ruby, using Enumerable, forwardable, and def_delegators. Go has no such deficiency. []Part does exactly what we want, and it is far more concise (Update: Ruby's SimpleDelegator looks a bit nicer).

Interfaces

Polymorphism in Go is provided by interfaces. They are satisfied implicitly, unlike Java & C#, so interfaces can be defined for code we don't own.

Compared to duck typing, interfaces are statically checked and documented through their declaration, rather than through writing a series of respond_to?tests.

"It is impossible to create an abstraction unknowingly or by accident; in statically typed languages defining an interface is always intentional." -Sandi Metz

For a simple example, let's say we didn't want to print the NeedsSpare flag of Part. We could write a String method as such:

func (part Part) String() string {

return fmt.Sprintf("%s: %s", part.Name, part.Description)

}

Then the calls to Println above would output this instead:

[chain: 10-speed tire_size: 23 tape_color: red]

[chain: 10-speed tire_size: 2.1 rear_shock: Fox]

[chain: 9-speed tire_size: 28 flag: tall and orange]

This works because we have satisfied the Stringer interface, which the fmtpackage makes use of. It is defined as:

type Stringer interface {

String() string

}

Interface types can be used in the same places as other types. Variables and arguments can take a Stringer, which accepts anything that implements theString() string method signature.

Exports

Go uses packages for namespacing. Identifiers that begin with a capital letter are exported. To make an identifier "private" to a package, we just start it with a lowercase letter.

type Part struct {

name string

description string

needsSpare bool

}

To apply the uniform access principle to the Part type, we could change the struct definition and provide setter/getter methods such as:

func (part Part) Name() string {

return part.name

}

func (part *Part) SetName(name string) {

part.name = name

}

It's easy to determine what is using the public API vs. internal fields or methods. Just look at the case of the identifier (eg. part.Name() vs. part.name).

Notice that we don't prefix getters with Get (eg. GetName). Getters aren't strictly necessary either, especially with strings. When the need arises, we can always change the Name field to use a custom type that satisfies the Stringer interface.

Finding Some Privacy

Private names (lowerCase) can be accessed from anywhere in the same package, even if the package contains multiple structs across multiple files. If you find this unsettling, packages can also be as small as you need.

It is good practice to use the (more stable) public API when possible, even from within the same class in classical languages. This requires convention, which we can certainly apply in Go.

The Good

The best thing about google programming language Go is that it was clearly designed to work on huge projects in a group with a modern edition control system.

Visibility

Go Language is case sensitive to specify visibility. Visibility is implemented at the level of the package instead of having a system of private, public and shared class members. Uppercase names like var X are publicly visible, where as, lowercase names like var x are visible only from the current package , and so on for types, methods, functions, struct members, etc. To implement visibility at the package level instead of the class level is the right mechanism. If one has written two classes in same package then It does not matter if any class of this package poke around in other class’s internals, subclass etc. If a class is in a different package, in that case one wants to know what is in the public facing Application Programming Interface (API) of the class. Go’s principle is easier and simpler. Small amount of time is required to get the idea that in name .Name the first thing is without doubt a package name and the second thing may or may not be a type, not like old programming languages, where usually the classes are only things with CamelCase names, but once on regulate, it is fine and guide to better API . If one wants to allow others to import something from ones package will simply use uppercase but if doesn’t wants to allow it then use lowercase

The people who are complaining against it are only the competitors who are giving baseless arguments to make the Go language controversial.

An other good feature of Go language is that it makes the directory the basic unit of package, which provides an opportunity to run and compile a file by using go run filename.go, Go also supports to set the $GOPATH as environmental variable and then put the projects into $GOPATH/src/projectname/. On running Go install project, it will compile that directory and put the executable into$GOPATH/bin/. It provides several advantages. First, as it is done by directory, one can make its own git (or whatever) storage area for each package. Second, if project file gets too long, one can break it up into multiple files which are, at compile time, automatically stitched into one. Third, despite of Python’s virtualenv. If one requires to have installed different versions of the same library for two different projects, just switch between two different $GOPATHs. Fourth, In this Language imports are always either rooted in $GOPATH/src/ or in the built-ins ($GOROOT/src/pkg/).

Fifth, this show the way towards the convention of using directory names instead of using domain name. So, if one has a GitHub( is a web-based hosting service for software development projects that use the Git revision control system account) one would store local stuff in $GOPATH/src/github.com/username/project/. If one runs go get github.com/userA/project/ it will download project from github.com by using git and put it into a proper place the go tool can download and install any library in the right place. So, in one hit, Go has its own graceful way out to packaging and a modern, decentralized version of CPAN ( Comprehensive Perl Archive Network has over 25000 open source modules available for download).

The Good

The best thing about google programming language Go is that it was clearly designed to work on huge projects in a group with a modern edition control system.

Go Language is case sensitive to specify visibility. Visibility is implemented at the level of the package instead of having a system of private, public and shared class members. Uppercase names like var X are publicly visible, where as, lowercase names like var x are visible only from the current package , and so on for types, methods, functions, struct members, etc. To implement visibility at the package level instead of the class level is the right mechanism. If one has written two classes in same package then It does not matter if any class of this package poke around in other class’s internals, subclass etc. If a class is in a different package, in that case one wants to know what is in the public facing Application Programming Interface (API) of the class. Go’s principle is easier and simpler. Small amount of time is required to get the idea that in name .Name the first thing is without doubt a package name and the second thing may or may not be a type, not like old programming languages, where usually the classes are only things with CamelCase names, but once on regulate, it is fine and guide to better API . If one wants to allow others to import something from ones package will simply use uppercase but if doesn’t wants to allow it then use lowercase

The people who are complaining against it are only the competitors who are giving baseless arguments to make the Go language controversial.

An other good feature of Go language is that it makes the directory the basic unit of package, which provides an opportunity to run and compile a file by using go run filename.go, Go also supports to set the $GOPATH as environmental variable and then put the projects into $GOPATH/src/projectname/. On running Go install project, it will compile that directory and put the executable into$GOPATH/bin/. It provides several advantages. First, as it is done by directory, one can make its own git (or whatever) storage area for each package. Second, if project file gets too long, one can break it up into multiple files which are, at compile time, automatically stitched into one. Third, despite of Python’s virtualenv. If one requires to have installed different versions of the same library for two different projects, just switch between two different $GOPATHs. Fourth, In this Language imports are always either rooted in $GOPATH/src/ or in the built-ins ($GOROOT/src/pkg/).

Fifth, this show the way towards the convention of using directory names instead of using domain name. So, if one has a GitHub( is a web-based hosting service for software development projects that use the Git revision control system account) one would store local stuff in $GOPATH/src/github.com/username/project/. If one runs go get github.com/userA/project/ it will download project from github.com by using git and put it into a proper place the go tool can download and install any library in the right place. So, in one hit, Go has its own graceful way out to packag and a modern, decentralized edition of CPAN ( Comprehensive Perl Archive Network has over 25000 open source modules available for download).