Go looks very cool but it solves only a subset of C++ better than C++. For example, I doubt very much Crysis, Battlefield or Modern Warfare could be written in Go on consoles assuming Go even existed on consoles.
Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. Or how about iOS and Android games, two places that use lots of C++?
So at least for me, while I'd love to get the benefits of what Go is trying to achieve, until it solves the problems I personally need to solve it's unfortunately off my list.
When I am on a project it fits I'm looking forward to checking it out.
Go is certainly not (yet) ready for every task C++ has taken over during the last 25 years.
But I would say that for most tasks, it is more than good enough already.
> Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows.
This is very easy in Go, just name your file foo_windows.go, foo_linux.go, etc. See for example:
Define "most". It's not suitable for any app I've written in the last 25 years. But I don't do server work, I do client work. Native apps on Windows, Mac, Linux and consoles.
It might be useful for some command line tools I've written but since nearly every command line tool I've written in the last 25 years has been to make data for my C++ client side apps there's a benefit to being able to share code.
Of course I know that's just one anecdote, mine. If it fits most of your use cases awesome.
For me, one thing that might go a long way to use Go is are cross platform client side libraries like WinForms. Once of the things that makes C# so popular with my crowd is how easy it is to make tools with GUIs. Of course C# also interfaces with native data pretty well. No idea how well Go handles that case
I don't see any reason to prefer Go to the D programming language. D achieves all the major claimed benefits of Go and yet has vastly more abstraction power and better type safety and error handling. The interest in Go is a mystery to me.
Is it really a mystery? It was created by some of the most well known computer scientists of the last several decades and was created by and for systems engineering at Google.
The interest in a language with even more features than C++ is a mystery to me.
If you read the linked article you will realize that the main benefits of Go are precisely from "features" that it omits. D takes almost exactly the opposite approach, and takes C++ and adds even more.
The lack of generic programming in Go is a huge deal. It's vital for modelling complex systems without a mess of runtime checks, and generally leads to clean and reusable designs.
With D, you can get very close to the generic ideal, "This
is the last implementation of linear search I'll ever need
to write." Or binary search. Or stable matching. Or
Levenshtein distance. I searched around, and it looks
like D is the only language offering Levenshtein distance
on UTF strings without copying the input and without
special-casing per encoding. D just has the abstraction
power to deal with variable-width entities efficiently
and within a unified definition (that works with many other
inputs, such as linked lists of floating point numbers, if
you want). It's really the last Levenshtein implementation
I need to write. Now, you may not care about that particular
algorithm, but there are benefits of that power for many
structures, algorithms, and design artifacts that might be
important to you.
Similarly I'm not sure how great it is at client side apps where you need certain code for OSX and different code for Linux and yet different code for Windows. Or how about iOS and Android games, two places that use lots of C++?
So at least for me, while I'd love to get the benefits of what Go is trying to achieve, until it solves the problems I personally need to solve it's unfortunately off my list.
When I am on a project it fits I'm looking forward to checking it out.