[venuzr]

Nope. This mostly becomes a problem if you like to be DRY and try to replace generics (type T) kind of functionality with interfaces. For e.g., I have a method, which does the classic, lookup from cache first before hitting the actual db. In C#, you can use

  public T Get<T>(int id, string cacheKey) {

  }

When I consume it and say Get for User object, I expect an User object as I already know it's type.

In Go, you have to return an interface (and ideally an error)

Here would be the equivalent,

  v, err := s.Get(id int, cacheKey string)
  if err != nil {
           //Handle error here
  }
  if v == nil || v.(*models.User) == nil {
		return nil, http.StatusNotFound
  }

Its a bit more code, but on the flip side, it gets you thinking as a client of all the things that can go wrong with your code