Go Is a Shop-Built Jig

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.

That's what we call struct embedding. Check this http://talks.golang.org/2014/go4java.slide#33 for more details.

There are plenty of go fanboys out there who will rage about go getting any kind of criticism, but this was a really thoughtful take on why go is a good practical language despite the problems.

Being able to fire up a fully formed, non-handicapped environment consisting of only vim and some command line tools is great. I've tried repeatedly on the JVM to accomplish this and always end up back with bloated IntelliJ and the vim plugin as my only option.

I would say that in the last 15 years I've used inheritance correctly a handful of times, embedded structs are nearly always the correct solution to data structure reuse problems. That Go prioritizes composition over inheritance for data structure reuse is one of its fundamental value propositions, that anyone that has used Java extensively thinks otherwise is baffling to me.

If Go had a longer history I'd probably argue the exact opposite conclusion of you. If you are a small shop with scanty resources and need to build practical business solutions Go seems like a great choice. Conversely, if you are able to afford the best developers and have massive enterprise software needs, maybe Java or .Net makes more sense.

I think what the grandparent poster meant to say was:

>Working in the enterprise, features like exceptions and generics make it easier [...]