Hehehe it is funny Peter, how we on this topic have pretty much reached the opposite conclusions. I honestly don't see a value for Go for very small teams.
What the creators of Go pitched the language for was specifically for Google scale development, and that makes sense to me. The very small set of features and simplicity of the language makes it well suited for very large scale development with huge number of people who will often be junior developers with minimal training.
The problem with langauge like Java and C++ for large scale development IMHO, is that there will always be somebody who screws up and use features in a bad way. You end up with complexity and scalability problems which are hard to deal with down the road. Go is simply to simple to make fundamental mistake like that.
I've been a C++ developer for over 15 years. And in my experience it is a language that is just rife with ways of shooting yourself in the foot. In fact what immediately appealed to me when I first chanced upon Go was seeing how so many of the problems I have seen over the years in large scale C++ development had been essentially solved.
I used to write long documents about all sorts of C++ features that would screw up things, where I encountered them etc. With Go most of these problems would have gone away. With C++, you can by accident walk into a circular dependency hell. Not with Go.
With C++ you can create static initialization and deinitialization mess. Not with Go. It is simply not technically possibly.
Both Java and C++ allows screw in how virtual calls are made. E.g. you cannot have an indirect call from your constructor to a virtual method. Again impossible to screw up in Go.
If you think modern business programming has to have full OO support, then I challenge you to come up with an example, that I could not solve with Go features ;-) I think you would be surprised by how flexible Go is.
Back to why I don't think Go is great for small teams. it is not that I think it is bad. But much higher productivity languages exist than Go, but which often require more specialized skill. That doesn't work for very large teams where people come and go. But I would argue that for small stable teams LISP, Smalltalk, Haskell, OCaml, F#, Clojure etc will often be superior choices.
With respect to Java and C++, I would say this: I don't do much Java, but I cannot see why Kotlin would not be a better alternative in almost every case where Java is used.
C++ is a bit tricker to define. Depends a lot on what you are doing, libraries that exist etc. But between them Objective-C, Go, Rust, Swift and Julia can IMHO replace pretty much all C++ usage. With the caveat that you don't have a requirement that you need to interface with a C++ library.
Anyway just my opinion based on what I've read and what I know. I have never built anything large in Go, but I have built large stuff in C++. Somebody who has made large stuff in Go would have to pitch in ;-)
