I do the same thing. Not because I can't write C++11, but because I still encounter systems with older compilers that I want to run programs on. What, is this surprising?

Let's face reality: it's a little unreasonable to expect every system you work on to have a compiler less than 3 years old.

Especially true on older Linux systems, it's sometimes a massive pain or even pretty much impossible to upgrade the existing compiler in a package-manager-friendly way (try upgrading Ubuntu 12.04's compiler to GCC 4.9, for example), so you'd have to compiler the compiler from scratch. Which is a pretty massive PITA and more or less requires a PhD of its own for GCC (Clang is a little better). And on Windows VC++ isn't always exactly following the correct standard. It's not necessarily outright impossible, but it's pretty impractical.

If you are running Linux, this is one thing that Windows gets right. (Although as you say VC++ has some catching up to do still).

For example I had a building machine running RHEL 5 which was building for both RHEL 5 and RHEL 6 while using gcc 4.8.2 for both (cross compilers).

See also https://en.wikipedia.org/wiki/Cross_compilers#External_links

I've hand-built GCC for half a dozen of different target architectures over the years and it's perhaps one of the most stable pieces of software when it comes to building it. I've only had one build failure over the years and that was unstable from git (even that usually works no problem).

To build GCC, follow the simple steps on the GCC manual. With a modern fast computer, it's all done in an hour or two (of mostly waiting).

If you're dealing with bare metal projects (kernel programming or micro controllers), building binutils and gcc for cross compiling from source is pretty much required. There are scripts that help and some distros have cross compilers in their package managers.

But building GCC is not difficult and it pretty much works first time, every time.

This is your problem.

Build a new compiler using the old compiler and install the entire new toolchain in /opt/my-gcc-4.9-0xfoof . rsync this new compiler to any machine you want. The package managers (people and code) a here for our suffering.

Still no exceptions, though.

The thing is, when you have a single codebase that is maintained by thousands of engineers, you have to make concessions. There is no place for "rockstar programming": everything must be, in a sense, bland, so that it blends seamlessly into the work of thousands of others.

I don't really understand organisations that still use C++ in 2014 but then knock out such fundamental parts of its functionality, but then looking at the design priorities for Go, clearly at least some people at Google have very different preferences to my own, so YMMV etc.

In any case, the decision was made, and we have millions of LOC where every single API is built with the assumption "No exceptions here." In that context, introducing exceptions seems suddenly a lot more trouble than its worth. Well, YMMV, and in any case I'm not a decision maker so what do I know.

* BTW, I think "a single codebase maintained by thousands of engineers" is the single best thing I found in Google, as it opens up infinite possibility of learning new tricks, new APIs, and sometimes new projects. (Of course, everybody complains that every API is implemented at least three times, but imagine how worse it would have been if every project had its own codebase.)

Also no exceptions implies no failing constructors which is plain ugly as a constraint.

In general if you're going to work with other people I believe you need to be a bit flexible on coding with them rather than trying to be hard headed about your own style. It's important that people not be surprised when they work with your code.

* Don't use var

* Don't use dynamic

or even better,

"You've only got .NET 2/3 installed"

That said it's quite expressive now, you can do a lot with a little code, which is always nice.

With this argument, every release that adds a new keyword (for example) would have to be given a new name, since it will very likely break some code. Question that remains is how much must the changes be before the thing deserves a new name.

I don't think the idea is to force existing software to be rewritten. It's to provide a clean break so that new software isn't saddled with the baggage of the old. Over time, most of the older software is retired or replaced, and the industry migrates to use the better tools with more and more projects.

This seems a very reasonable strategy, as long as your ABI or equivalent interface specifications can remain compatible for the common subset of functionality, so that programs built using the new language can still use libraries written in the old one. (See also: Every successful general purpose programming language in decades has offered a FFI for C.)

It doesn't work so well if you don't have proper formal standards for your old and new languages. It's also much harder to achieve in practice if your code is effectively running on some sort of virtual machine so you can't have that clean break at the ABI level, which might be one reason why several languages have failed to make a convincing big jump in recent years (Perl 6, Python 3, etc.).