Google Developers Begin Planning For Go 2 Programming Language

[plonoma]

How odd, most languages that insist on backwards compatibility become nearly unusable to the point where the only thing that matters to it is backwards compatibility.

Yes this.
Backwards compatibility at all costs is a dead end for programming languages.

[mr_tawan]

Sounds like "goto' to me .

[plonoma]

Sounds like "goto' to me .

Do not go to that joke.
Goto considered harmful.

[cl333r]

Python 3 has been out for a long time now and yet 2.x is still the default in almost all Linux distributions.
I am almost tempted to say that Python 3 is actually pretty "niche".

No, actually everybody is moving to Python 3, including Ubuntu and Fedora, I just didn't check because I don't care about Python.
It's just that Python is not the only cool scripting language anymore.

[Michael_S]

yet it's not dead and people are moving to it.

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.

[Michael_S]

Yes this.
Backwards compatibility at all costs is a dead end for programming languages.

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?

[kpedersen]

Goto considered harmful.

Not at all, when used correctly. For example in memory management it provides quite a nice pattern.

You can see it used extensively in the OpenBSD kernel.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/dev/ata/wd.c?rev=1.122&content-type=text/plain

i.e imagine ths following:

struct Test *t1;
struct Test *t2;
struct Test *t3;

t1 = malloc(sizeof(*t1));

if(!t1)
{
  return 1;
}

t2 = malloc(sizeof(*t2));

if(!t2)
{
  free(t1); // don't forget
  return 1;
}

t3 = malloc(sizeof(*t3));

if(!t3)
{
  free(t1); // don't forget
  free(t2); // don't forget
  return 1;
}

free(t1);
free(t2);
free(t3);

return 0;

I would much rather maintain this because it will be harder to forget to clean up the memory:

  struct Test *t1;
  struct Test *t2;
  struct Test *t3;
  int rtn = 0;

  t1 = malloc(sizeof(*t1));

  if(!t1)
  {
    rtn = 1;
    goto end;
  }

  t2 = malloc(sizeof(*t2));

  if(!t2)
  {
    rtn = 1;
    goto end;
  }

  t3 = malloc(sizeof(*t3));

  if(!t3)
  {
    rtn = 1;
    goto end;
  }

end:
  free(t1);
  free(t2);
  free(t3);

  return rtn;

[carewolf]

"Go 1.x code will continue to work in Go 2. "

This is not a feature but a requirement for any language. If not, it is dead on arrival because we know Go 3 will break it all yet again.

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?

[carewolf]

The Python 2.x -> 3.x breakage is actually one of the reasons we stopped using it. So many libraries work on one but not the other, it isn't worth the time faffing with it.

VB6 -> VB.NET pretty much killed Visual Basic

C/C++ are not exactly what I would call bloated languages, but they retain fantastic backwards compatibility.

Yeah, I am simply not touching a language that breaks compatibility. Developing robust software is hard enough without rewriting it every so often.

Both C and C++ has broken compatibility in their standard libraries, and other more modern languages have a less clear separation between standard libraries and the language. So it is a bit unfair, on the other hand the ability to work without the standard library, it is why C and C++ are system programming languages and the rest are not.

[kpedersen]

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.