Sunday, May 29, 2016

Things that I miss in Golang

Go is a nice language and I feel it sits somewhere between C and C++. It has good libraries. Very good Concurrency support can make creating highly concurrent application much easier. Goroutines and channels are great and they help in creating simple and efficient programs.

But Go still lacks many facilities that C++, Java, Python provides. Below are the list of features I wish Go would have included:

  1. Default parameters for functions or methods: Go doesn't have this feature. That makes things awkward sometime. Let us say, I am writing a realtime data-processing pipeline in Go (trying to emulate Storm in Go). Each stages in the pipeline may emit a tuple calling the method collector.Emit(tuple). Now I wish to add the feature of tracking a tuple tree. I want to signal that tracking is needed. I would have loved to do that using the same method, something like  collector.Emit(tuple, context) where context may be some struct containing the tracking information. Let us say, we could have declared the method as shown below: 

    func (collector *Collector) Emit(t Tuple, context *Context = nil) {
        ....
      
    }

    We can do this in C++ and Python. Method overloading is available in Java too. Wish we could do the same in Golang as well. It is not a thing that we cannot work around. But suppose I designed Emit the method without the tracking stuff in mind and later I wanted to add the tracking part; then the default parameters will help as I don't need to change my existing application code that will use the pipeline library.
  2. No great  debugger bundled with the Go distribution I download from Google. Gccgo has integration with GDB, but I don't use gccgo. Having a good debugger is a great help for lesser mortals like us. Java/C++/Python/C doesn't have this problem.
  3. Lack of inheritance: This hampers our ability to re-use code. Most probably because, Go is not a purely object oriented language and it wanted to have minimal support for OO paradigm. 
  4. Type safety is less:  In Go programs, we tend to pass interface{} as parameter too often. But that is like void * in C/C++ or Object in Java. If we had inheritance in Go, and if we could make a base "class" pointer/reference to point/refer a derived class object, things would have been really safer and easier to reason about.
  5. It is difficult the find out which "base" interface this particular "class" has implemented. Only way out is to do a lot of grep on the code. 
  6. No generics:  We end up writing the same code for different types, which could have been avoided if we had generics
  7. No exception handling: I have used Java/C++ a lot. Lack of exception handling means, we have to check the return status of functions everywhere.