[ndh2]

Lots of posts here frame it like "Yes, it's a bit of a complex language, but the C++ committee has the difficult job of keeping everything backwards compatible, so it's understandable." But that's not the reality. The reality is that they (or Stroustroup) made that decision, and that decision was a mistake.

The correct way to deal with backwards compatibility issues is the way Go does it, namely to write tools to automatically upgrade code to a newer API [1]. And as that smug Google guy explained here [2], they have something like this for C++, too. They just don't bother sharing it with us peasants.

The fundamental mistake of C++ is to religiously keep backwards-compatibility with everything for all eternity. It's so easy to say that backwards-compatibility is a good thing. It's obvious! But ultimately that decision is the reason for all the problems that C++ has.

[1] https://golang.org/cmd/fix/

[2] https://www.youtube.com/watch?v=tISy7EJQPzI

[blub]

Apple can't write a tool to properly update automatically between Swift versions today, but according to you, this could have been done in the 80s or 90s for C++ which is notoriously hard to parse...

[ndh2]

I didn't say that.

It's not the 80s anymore, and the reason that C++ is still and will always remain hard to parse is... backwards compatibility.

[gpderetta]

Backward compatibility with C semantics and tooling was fundamental for C++ success. We wouldn't be having this discussion otherwise as nobody would have used C++.

Tools are great for minor upgrades of APIs and syntax, but key to C++ was compiling with existing system headers (no, realistically you do not want to maintain your own 'fixed' version), and most importantly OS and library ABI.

[pjmlp]

AT&T had a Java like variant of C, before Java was even a thing, called C+@.

This DrDobbs article in an 1993 issue dedicated to possible successors to C, is the only proof that it ever existed.

http://www.drdobbs.com/article/print?articleId=184409085&sit...

Print view is the only way to read it properly.

[ndh2]

I agree. I said that it was a mistake, but in the beginning it really wasn't. It's just not a viable long term strategy in my view.

[kibwen]

This comment is far overestimating the capabilities of gofix. And this isn't a denigration of gofix (which is a good idea in general that more languages should copy), it's simply that Go actually really didn't change very much between 2009 (when Go was publicly announced) and 2011 (when Go 1.0 arrived and things stopped changing). It certainly didn't change nearly as much as "idiomatic" C++ has between 1990 and today.

The lesson here is that languages should restrict their backwards-incompatible changes to only those that are amenable to automatic migration via limited gofix-like tools, but that runs counter to your argument that C++ ought to be casting off its C heritage (which I quite sympathize with).