sat
This is not to say go is bad at all. Its been designed by people 1000x smarter than me. But it isn't helping small shops go any faster or be more productive than they are with current setup. Talk about progress of the 21st century programming language...can't find much.
Bloated it may be but helps me get the job done faster...much faster than I can do it in vim. I work on a mac with 16 GB RAM and thats sufficient for lots of processes. Every bit of the way, I have documentation I can lookup right within as I type, I have autocomplete that always works, I have debugger support to catch little things I missed, tons of libraries and plugins that have stabilized over the years...whats not to like? The downsides (and the reason I looked at go) are both Java and .Net are memory hogs. I needed something more lighter that would offer the same level of productivity during development.
This is not to say inheritance is better. I am just illustrating how reuse is harder with go because it expects a lot more code to do a simple thing.
I found it hard coming from a world where IDE support was available in other languages that do autocompletion and things like that and development just moves faster. In go, there is some level of support in sublime text, go for vim etc, but it is not nearly as full featured as say, IntelliJ. Want to learn about the javadoc - Command + J. Want to refactor code, much easier than in go. So tooling is a big problem I encountered.
Next in line is lack of reusable data structures. Sure, embedding of structs is supported, but lets see...what will you do with a person struct (name, age, gender) that should be part of a employee struct and also the executive struct. You have 2 options 1) copy paste the person struct fields into each of the other structs or 2) you have interfaces and implementations of those interfaces so you can only deal with it through interfaces using embedded structs. What we really want is a flattened struct (just like inheritance). Most time people use inheritance not because its the right thing to do for that piece of functionality, but because it allows easily flattening out a data structure so you have reuse of a common data structure with common properties across other data structures. This one killed it for me with go. I can't reuse. I am not google to have loads of dollars and when I try to make things work, I need to be able to keep an eye out for bugs that can creep in with go where re-use is artificial or takes excessive work to get.
All in all, maybe go has its niche, but for a small shop that runs on scanty resources and needs to build robust and reliable applications, a heavy weight like Java or .Net is still ruling the roost.