Actually, If you have invested the 15+ years it takes to become a decent C++ programmer, then you won't want to throw that out just because some new language comes by.
Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance.
And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't.
Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.
If you have invested the 15+ years it takes to become a decent C++ programmer
I have been programming in C++ for the past 14 years. Other than fast compile times, and a little less work to wire up interfaces, what exactly I am I supposed to be drooling over Go for? Between RAII and other modern C++ practices I don't really feel the need for a garbage collector. I already have a library that gives me Channel like functionality. I am sure if I really wanted green threads I could find an implementation that was similar to goroutines. Basically when I get excited about new programming languages it is about languages different enough from C++ that they actually have a shot at being better, Clojure, Scala, and Haskell come to mind.
A language that doesn't affect the way you think about programming, is not worth knowing.
Edit: I am fully aware that I may be blind. I do plan on exploring Go at some point, but exploring other more exotic languages take priority for me.
Aw, how did you guess. What did you find full of it? In GC languages you still have to have to manage reference life times so that you don't leak memory by holding on to references too long(Yes I have fixed that bug in someone else's C# code). If you are already doing all the reference tracking what is wrong with making it explicit and typing the delete? Good build tools doing the minimal rebuild thing make builds manageable, sure Go's are faster but it wasn't a pain I was feeling, or have lived with so long I forgot. So for me the differences boil down to type safe generics vs the way interfaces work. Go is a worthwhile experiment(God I hope Google is doing IBM style research on Go's effect on quality, and that they share it) in how to make development better, but I don't currently think I will see enough payoff to justify the effort of switching. That is especially true when you consider all the external tidbits like library support.
Nope, not that guy. stonefarfalle on reddit. I probably am full of BS(after all the mouth is large and rarely closed for business), but a little too proud, and prudish to call myself that in public.
Most of what happens in C++ is low level maintenance of data. There are certain programs where this is important, but for the largest chunk of programs, low level maintenance provides more buggy programs with considerably worse performance.
And this is the real crux of the problem. For some C++ programmers they wont or simply can't give up the low level ability to mangle data. I have a hunch though that certain lacking constructs, generics come to mind, are used as excuses for not even wanting to take a decent look at the language. I have a feeling that sometimes it ends up being a religious tirade because "then I can't do my own containers". But you really shouldn't.
Most dynamically typed languages do not really need a generic-primitive. Does that make them unsuitable for programming? Hardly. In Go you just have to work around the problem.