A Practical Look at Go, Part 2

1 Comment

By Ken Walker Senior Software Engineer

In part 1 of this article, we looked at Go’s support for multiple threads and its approach to error handling. In this part, we’ll look at how Go approaches object orientation and how this would affect your daily routine.

Object Orientation (sort of)

Technically there are no classes in Go. But you can define methods for data types so you can get partway to object orientation.

type YourMind {
    IsOpen bool

func (ym *YourMind) Open() {
    ym.IsOpen = true

You can also define interfaces. However, you do not explicitly declare in your code that a data type implements an interface. If your team writes methods on a data type that match each one defined in an interface, you can say amongst yourselves that the data type implements that interface. However, the compiler never knows, so it can never help you identify the case where you missed one of the methods.

There are, of course, several ways this problem will be detected at runtime. To catch this problem at compile time, you have to add an extra line of code:

var _ CanBeDriven = (*Building)(nil)

(Some specifics of Go syntax: Generally, a variable declaration takes the form of var name type = value. Specifying “_” for name means go ahead and evaluate value, then discard its value.)

For safety, you’ll want to make sure your unit tests include this statement as well as invocations of each of the methods of the interface.

This disconnect between interfaces and implementations can also be maddening when trying to walk through your code base. Tools cannot help you track down the possible data types that could get passed in if you have a function or method that types a parameter by an interface.

Garbage Collection

Go is a garbage-collected language. You do not have to explicitly allocate and release memory in your code.

Defer Statement

The defer statement registers a function to be run before exiting the current function or method. This is typically used for clean-up steps, such as making sure your file gets closed in all cases.

func AppendToUserFile(filename string) {
    data := GetDataFromUser()

    userfile, err := os.FileOpen(filename, O_APPEND|O_WRONLY, 0755)
    if err != nil {
        return // Point A
    defer userfile.Close()

    // Oops, user asked us to keep this quiet
    if data.Contains(“secret”) {
        return // Point B


(This example shows the other way to declare variables. If the data type is obvious from the initialization value, you can drop the var and use the := form of the assignment operator. Notice this can only be done within a function or method.)

In this code (written poorly for demonstration purposes) if an error occurs while opening the file we return at Point A and Close() is never called on it. But once the file is successfully opened we execute the defer statement to register the call to userfile.Close(). Now whether we return from the middle of the function (at Point B) or its end, userfile gets closed.

If you have multiple defer statements, their functions are run in the reverse order in which they were registered. This is very useful when the instances you have to clean up depend on each other.


When I was using Go, there was no real debugger to use. GDB had (and continues to have) only limited support. (You know you’re in for trouble when Go’s GDB documentation starts out by saying, “GDB does not understand Go programs well.”) Our primary tool was the age-old solution of log messages.

Online posts show a star appearing to have risen above the horizon: Delve. It’s a command-line debugger, à la GDB, and reports are that it integrates well into IntelliJ. In addition, someone has written a graphical front-end called Gdlv which you may want to investigate.


If these articles have piqued your interest in Go, here are a couple of places to continue your research:

A Tour of Go, which introduces you to the basics of the language. It includes playgrounds where you can edit and run Go programs related to the topics being discussed.

The Go Programming Language Specification.

Packages, documenting all the standard packages that come with Go.

Projects, which can help you begin to explore the other Go-related resources out there.

And, as always, Google is your friend; here not only to help you find more information (tip: search for “golang”), but also because they got the whole Go ball rolling in the first place.


Author: bridge360blog

Software Changes Everything.... Bridge360 improves and develops custom application software. We specialize in solving complex problems at every phase of the software development lifecycle, removing roadblocks to help our clients’ software and applications reach their full potential in any market. The Bridge360 customer base includes software companies and world technology leaders, leading system integrators, federal and state government agencies, and small to enterprise businesses across the globe. Clients spanning industries from legal to healthcare, automotive to energy, and high tech to high fashion count on us to clear a path for success. Bridge360 was founded in 2001 (as Austin Test) and is headquartered in Austin, Texas with offices in Beijing, China.

One thought on “A Practical Look at Go, Part 2

  1. Pingback: A Practical Look at Go, Part 1 |

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s