Abstract Libraries in Go

Share on FacebookTweet about this on TwitterShare on Google+Share on RedditShare on StumbleUpon

Go is by far one of my favorite programming languages to program in. In many ways, Go is a bridge between worlds, we have Python and Ruby dominating most scripting and C, C++, Java for doing heavy lifting (I grant you there are other languages just naming a few). The issue with C, C++, Java and the like, are that they are fairly complex, they offer you more control than Python or Ruby, but it comes at a cost of programmers. On the other hand Python and Ruby offer quick (often much quicker) programming solutions, at the cost of less control.

Go seems to bridge the gap between these two worlds. Offering a programming style similar to Python or Ruby, but with a fraction of the runtime [1][2]. Unfortunately for Go, it still cannot match the C, C++[3], and only semi compete with Java[4]. Granted, the compiler optimization for Go is at least several decades behind these languages. That being said, it’s fair to assume that as Go is optimized there will be increasing demand…

Hence, my efforts over the past few months to become a better Go Programmer. This week I spent time learning how to abstract libraries in Go. The easiest way to achieve this is using an interface. The following is code I used to create a graph library,

In the example above you can see the Node struct has a variable Data which is an interface{}. Declaring Data as interface{} allows a struct to initialize Data, and therefore a node in this graphing library can store anything (including another graph). This is probably one of the most important characteristics of Go and is why it is part of the reason Go cannot be considered object-oriented [5].

In practice, this allows for examples such as the following

As you can see node1 and node2 are both represented on the same graph, yet contain different data. Note that some other programming languages allow this as well, however usually not nearly as clean. This allows for both greater generalization of libraries as well as ease of readability, use and in turn programming time. Since in this day and age a programmers time is the most important commodity this is a big deal for general purpose programming.

Although Go programs may not run as quickly as C programs, for the most part this is not an issue. E.g. who cares if a program can serve up a webpage in .0002 seconds vs .0001 when the client will take .2 seconds to load the page regardless. In some cases clearly this is an issue, such as the guidance system for a plane, but for the most part it is simply not. I am sure when the authors of the Go language were building Go, this was in the forefront of minds.

If you are interested in seeing my full implementation of Dijkstra’s Algorithm and my graphing library, feel free to visit my github.

Recent Articles

Share on FacebookTweet about this on TwitterShare on Google+Share on RedditShare on StumbleUpon

5 thoughts on “Abstract Libraries in Go

  1. I wanted to comment, but had nothing to say, so I googled computational complexity jokes. Except there are none.

    So here you have it. The first joke about computational complexity ever written:

    “Hey, man, is there something wrong with your mom? Because I graphed her weight and she’s growing faster than a busy beaver function.”

  2. “Note that some other programming languages allow this as well, however usually not nearly as clean.”

    Can’t C++ and Java does this exact same thing with “void*” and “Object”? Am I missing something?

    And if you want more type safety, C++ and Java can do better than this with templates/generics.

    1. With C++ and C you have to worry about memory leaks, interfaces ensure that does not occur. As for generics, yes Java can do something similar.

      1. you mean with generics Java can do much *better*, not similar.

        No offence to Go, it’s a great language…but lack of generics is really painful if you’re used to it already.

      2. Without generics, a Java solution would use “Object”, which is similar to your Go solution. With generics, Java can do something better than Go. C# is similar.

        As for C and C++, you always have to think about memory management. It’s unrelated to this particular concept. With C++ templates you can do something better than Go. Plus, a solution that uses templates also allow C++ smart pointer types, which makes memory management easier.

        Which languages were you thinking of when you said: “Note that some other programming languages allow this as well, however usually not nearly as clean.”? Most statically typed languages solve this particular problem as well as or better than Go.

Comments are closed.