> "I'd be interested in hearing something from an expert C++ programmer who has really given go a try and decided it's not their cup of tea."
I am not a C++ expert but I have programmed a fairly amount of C++ code so I will give you my two cents.
I use C++ because a blend of three things:
* Performance,
* Abstraction and
* Portability.
If I would care just in a subset of that tuple I probably will code in something else.
For instance, if for some project performance is not an issue, I will probably use a higher level language like Python or Scheme. If I am feeling that Abstraction is not as important as performance and portability I will use C.
When I care about the three of them I feel there are not too many options.
I agree, in the games industry we use C++ for a few reasons:
* Performance
* Portability
* Direct API access (D3D, OpenGL, console specific APIs)
* Large legacy codebases
* Control over memory management
Go doesn't really address all these areas adequately at the moment from what I've seen. For me personally, for those problem domains where the above are not a concern I find other languages more compelling than Go - Haskell, F#, even C#.
It seems likely that a compiled functional language like OCaml or Haskell would do better overall - maybe a slight sacrifice in performance, but much more abstraction available, and greater portability since more of the library is standardized.
I am not a C++ expert but I have programmed a fairly amount of C++ code so I will give you my two cents.
I use C++ because a blend of three things:
* Performance,
* Abstraction and
* Portability.
If I would care just in a subset of that tuple I probably will code in something else.
For instance, if for some project performance is not an issue, I will probably use a higher level language like Python or Scheme. If I am feeling that Abstraction is not as important as performance and portability I will use C.
When I care about the three of them I feel there are not too many options.