> Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: who is still using C/C++ in 2014, and why? Here are some ideas:
I (and many others) "still" use C++ (which is a very different language from C) in 2014 because it's an extremely powerful language that's still evolving and has produced many innovations that haven't been replicated by many other languages, such as destructors/RAII, strong compile-time type checking, generic programming, and ownership/move semantics. To me, Go looks like an update of C that has ignored all the good innovations of C++. It has no destructors, uses GC instead of ownership/move semantics, and requires runtime type checking instead of providing generics. I see it as a big step backward from C++, so unlike Rob Pike I'm not surprised it hasn't attracted C++ programmers.
Rust, on the other hand, has taken many of the good parts from C++ and developed them even further, without the baggage of C++. Thus, while I haven't coded any Rust yet, it looks like a step forward from C++ and has me quite excited.
I apologize, "still" came off as pejorative. My post became a little muddled there, but had my thoughts been clearer, I would have focused on just one group: programmers who currently use C++ even though they would prefer to switch to another language. My interest pertains to them -- what requirements have prevented them from switching, and does Go satisfy those requirements?
>> [C++ is] still evolving and has produced many innovations
You're absolutely right, those features extend beyond performance/control.
>> Go looks like an update of C that has ignored all the good innovations of C++.
Yes, Go feels much more like an updated C to me too. And it makes it all the more surprising they expected C++ programmers to jump on board. I double-checked the quote, and actually C wasn't mentioned at all.
For me - it's because Go exists in the same uncanny valley as Java. It is a language that manages to get a good number of trade-offs right, balances performance & productivity, and provides a good all-around package.
However, it's not the best at anything. If you need super performance and the ability to control the machine directly, you still need C++. If you want super productivity and the ability to quickly try out ideas and see if they work, you still need Python or Ruby. If you want to write for web browsers, you still need Javascript. If you want to write for iPhones, you still need Objective C. If you want to write for Android, you still need Java. If you want to be absolutely certain your program will work as intended when it compiles, you still need Haskell.
I guess Go is the best mainstream language available in one area, networking concurrency. And that's where we see its successes so far - Cloudflare and Doozer (Heroku's Paxos implementation) and dl.google.com.
But virtually all the money in the tech industry is made on the margins - by being the best in the world at one specific task. If you want to build the fastest, most memory-efficient database possible - you still need C++. If you want to crawl, parse, and index the most pages on the web - you still need C++. If you want to have the highest-quality graphics at the best frame rate possible - you still need C++.
I could see Go getting pretty widespread adoption within the enterprise (as in, software departments of companies whose primary product is not software), much like Java has. There, you don't need to be the best in the world at something, you only need to make the best use of the computing resources you can with the staff you have available, and a language that gives you a good trade-off works out well. But these people moved away from C++ a decade ago; the enterprise is all Java land now. The people who still are on C++ generally work for product companies where performance is critical; because of the economics of the software industry, it pays for these companies to hire a few more expensive developers and ensure that their product remains better than the competition than to switch to a more productive language and take the risk that their technology stack won't let them achieve the goals that make them competitive.
I said mainstream. Erlang is better at concurrency & networking, but it has some very pragmatic problems (notably, string handling is dog-slow and takes lots of memory) that rule it out for many use-cases. The tooling for Go is also better than that for Erlang, the libraries for things other than telecom & messaging are more extensive, and you're more likely to find enthusiastic developers for it.
I definitely share this perspective, I think C++14 it's a great language and nothing I've seen about go has given me any interest in considering switching to it. Rust on the other hand looks really promising and has a bunch of neat innovations that make it seem pretty exciting to me and I'm definitely interested in learning more even though I'm by no means dissatisfied with modern C++.
The only other language I currently do any meaningful amount of coding in is F# and for me that replaces any need for a scripting language like Python or Ruby. I've used and liked Python but I really missed static typing.
I (and many others) "still" use C++ (which is a very different language from C) in 2014 because it's an extremely powerful language that's still evolving and has produced many innovations that haven't been replicated by many other languages, such as destructors/RAII, strong compile-time type checking, generic programming, and ownership/move semantics. To me, Go looks like an update of C that has ignored all the good innovations of C++. It has no destructors, uses GC instead of ownership/move semantics, and requires runtime type checking instead of providing generics. I see it as a big step backward from C++, so unlike Rob Pike I'm not surprised it hasn't attracted C++ programmers.
Rust, on the other hand, has taken many of the good parts from C++ and developed them even further, without the baggage of C++. Thus, while I haven't coded any Rust yet, it looks like a step forward from C++ and has me quite excited.