Google Developers Begin Planning For Go 2 Programming Language

[carewolf]

What C/C++ breakages are we talking about? I know there have been spec refinements (to prevent unstandard C compiler extensions from functioning) but as for breakages, the portable part of my Watcom C code from PC-DOS days still compiles perfectly on my modern Clang C compiler.

Also, deprecated features (i.e auto_ptr) is handled very nicely by compilers having flags such as -std=c++98 and this is unlikely to ever stop because C and C++ is too important in the lower levels of most software stacks.

Changes in the standard libraries. They have changed a dramatically a few times. The biggest one for C++ was the addition of the std:: namespace 15 years ago. But if we are just talking ABI it broke as recent as last year with libstdc++ changing fundamentals of the std::string implementation.

[kpedersen]

The std namespace was there for the first standard of C++. It is only non-standard drafts implemented by eager compiler developers (Microsoft C++ 3, Watcom 11) that excluded it.

As for std::string breakages, can you point me towards a specific one? I cannot seem to find anything about it. If you mean there have been internal std::string implementation changes... thats fine. That's not a breakage.

[bregma]

... if we are just talking ABI it broke as recent as last year with libstdc++ changing fundamentals of the std::string implementation.

If we're just talking ABI, it changes with every single release of Microsoft's compiler (and even the you need to link against a ship one of four variations of the same runtime to match the compiler options you used to build with). Turns out one vendor's runtime changes have nothing to do with the language: Microsoft is not a feature of the C language, for example. No change in the C++ language necessitated an incompatible change -- only a clarification of an ambiguity meant that the GCC implementation of std::string was no longer conformant. Go of course gets around the whole ABI question by supporting only a limited variant of that great 1950s invention, dynamic linking and declaring that dynamic linking is only valid if every single linkable module has been compiled with the same micro-point-release of the compiler (which is still effectively static linking, only at runtime).

[plonoma]

I think it's a dead end for open source programming languages. In the Python community, if you can't use Python 3, you can keep using Python 2 forever.

But if you have an application written in Microsoft Visual Basic, the changes between VB and VB.net might really burn you. Microsoft doesn't offer old VB any more, do they?

Breaking backwards compatibility in a language does not mean immediately dropping or neglecting your older language version.
Handling such a transition period with the right support timelines is what separates good language (compiler) makers from bad ones.

[nslay]

Changes in the standard libraries. They have changed a dramatically a few times. The biggest one for C++ was the addition of the std:: namespace 15 years ago. But if we are just talking ABI it broke as recent as last year with libstdc++ changing fundamentals of the std::string implementation.

No, they really haven't changed dramatically. Anything that happened either wasn't standard yet or were brand new features. I see C++98 had namespace std and to my knowledge, STL always used namespace std from day 1. Heck, I got stuff from 2004 that will still compile now with brand new C++ compilers.

The biggest change to STL I can think of is the recent/upcoming deprecation of std::random_shuffle in favor std::shuffle and use of generators from <random>.

C++98 tutorial with namespaces (using namespace std; in all examples):

http://www.cplusplus.com/doc/oldtutorial/

In the context of backward compatible language features in newer standards, ABI breakage is not relevant. C++ will probably always be plagued with potential ABI issues due to name mangling and stuffing everything in headers.

[mr_tawan]

Personally I think backward compatibility is very important. As a user, I don't want to unlearn and relearn things if I don't really have to do. I think, at least, backward compatibility at the syntax level should be provided. It's still OK to ask the users to recompile their code to run on the new run-time, but forcing them to update their code significantly might raise flags among users.

If there are things that really broken and needed to be replaced, deprecation is the way to go.

[mr_tawan]

No, they really haven't changed dramatically. Anything that happened either wasn't standard yet or were brand new features. I see C++98 had namespace std and to my knowledge, STL always used namespace std from day 1. Heck, I got stuff from 2004 that will still compile now with brand new C++ compilers.

The biggest change to STL I can think of is the recent/upcoming deprecation of std::random_shuffle in favor std::shuffle and use of generators from <random>.

C++98 tutorial with namespaces (using namespace std; in all examples):

http://www.cplusplus.com/doc/oldtutorial/

In the context of backward compatible language features in newer standards, ABI breakage is not relevant. C++ will probably always be plagued with potential ABI issues due to name mangling and stuffing everything in headers.

I've got some stuffs back to the VC++6 day, and it only need slightest changes to get the code compile in VC++2012 (I don't have the latest version at work, unfortunately). VC++6 has nasty non-standard for-loop that is on by default. They are all over the code base, but that's probably the only thing I needed to fix. Getting that done and the program works almost the same, at least in the user POV.

Of course it does not mean the code should stay at the VC++6 compatible. It's too old. However getting code slowly moving to the modern standard while the code is still running is much easier than dealing the code that does not run at all (like in the Python 2-3 cases).

[mr_tawan]

But then later they say: "After all the backwards compatible work is done, work will start on the backwards-incompatible".. So it go1 code will only work on go2 to begin with?

I think that means, they will work on the feature that exists in go 1 first, then the new features would be added thereafter. The code written in go 2 will not compile in go 1 compiler.

[carewolf]

No, they really haven't changed dramatically. Anything that happened either wasn't standard yet or were brand new features. I see C++98 had namespace std and to my knowledge, STL always used namespace std from day 1. Heck, I got stuff from 2004 that will still compile now with brand new C++ compilers.

The biggest change to STL I can think of is the recent/upcoming deprecation of std::random_shuffle in favor std::shuffle and use of generators from <random>.

C++98 tutorial with namespaces (using namespace std; in all examples):

http://www.cplusplus.com/doc/oldtutorial/

In the context of backward compatible language features in newer standards, ABI breakage is not relevant. C++ will probably always be plagued with potential ABI issues due to name mangling and stuffing everything in headers.

As someone who learned C++ in the mid-90s, I would disagree. Just because it wasn't an ISO standard didn't mean it was a real language that people used, in many ways it wasn't as different from many other new languages that need a revision or two before they settle down, though with C++ it was fortunately mostly in the standard library, and no one was really using that in the begining because it wasn't stable or done yet.

Btw, I wouldn't recommend trying to compile old code from 2004 with modern compilers. While the language is mostly compatible, the quirks, extensions, warnings and low-level stuff changes all the time, and some C++ developers (especially on performance critical frameworks) have a tendency of pushing the language well into undefined territory. As someone working on Qt and Chromium I can tell you, that for every new compiler released we need to make minor changes to make it even compile with a newer compiler. Though it happens much much more with Chromium than Qt.

[Delgarde]

I agree that Python 3 is not dead and people are moving towards it. But it really did hurt the adoption of Python. So in that sense kpederson and Delgarde are right. A lot of major open source projects in Python stalled when Python 3 came out. Some still haven't been ported over. virt-manager is still, as far as I know, in Python 2. Saltstack is also, as far as I know, in Python 2.

The problem, as I saw it, was mostly around the ecosytem rather than the language itself. For pure-Python libraries, the tools for automated 2->3 conversion were decent - not perfect, but adequate. But a number of heavily used libraries - mostly those relying heavily on C bindings - were very slow to port, and that hindered porting of many others that depended on them... which also meant the distros were slow to move to 3 by default.

Collectively, those delays really slowed down the migration to Python 3... and they did so right about the time that Node.js came along, seizing a lot of popularity (especially for web work).