Introducing Go 2.0

This is a creation in Article, where the information may have evolved or changed.

Just so we ' re clear, the This post was a thought experiment, not any form of the commitment to deliver Go 2.0 in any time frame. While I personally believe there is a Go 2.0 in the future, I ' m in no position to influence its creation; Hence, this post is mere speculation.

Why introduce a new major version of Go?

Go 1.0 was released over 4 years ago, and since then the Go 1 compatibility contract have been a boon to anyone investing I  n Go as the language to build their product. So, why introduce a new version of Go?

By the time this Go 1.8 is released at the start of the library would have accumulated cruft and hacks for F Ive years, and if you consider so Go started life in, it's closer to ten. An opportunity to address this cruft and remove some of the packages which is now understood to being a bad idea would make The standard library is more consistent and approachable to newcomers.

It is possible the language itself could become smaller. Rob Pike noted in from that there is too many ways to declare a variable on Go, and this could is rationalised. Similarly the incongruence between make and new might be resolved. Then there are the problem of non Latin characters not being considered upper case. So, lots of little cleanups to do.

Obviously some kind of solution for templated types would has to is part of the any Go 2.0 discussion and, as David Symonds p ointed out several years ago, they would has to is used to rewrite the standard library, both causing, and justifying, th e compatibility break.

Backward compatibility

Backwards compatibility is isn't about syntax or features, backwards compatibility are about investment. Investment in the language; Both at a technical and career level. Investment in libraries. Investment in backends this generate machine code. Investment in the mid part of the compiler, that transforms and optimises code. Investment in build scripts and toolchains this embeds one piece of compiled code into another.

Brian Goetz, the Java language architect, describes the commitment to backward compatibility as the ' Central Park effect '. This is something we cousins in the hardware world has a long understood–never let the customer Unbolt your product from The rack, ' cos they might take the opportunity to use that space for your competition.

The lessons of Python is prescient; Ignore backward compatibility at your peril. No matter how compelling the new version of your language, if you do it incompatible with the investment in the previous version, launching a new product which is in direct competition with itself. And just to make it clear, I'm not picking on Python specifically, there is plenty of other examples; D 2.0, Perl 6, and vb.net also come to mind.

All of these examples show the danger of creating a new version of a language that requires it users to rewrite all the source of their program, including all their dependencies (which could be non trivial), before it would comp Ile and run.

A plausible implementation

So, what to create a new Go 2.0 language, with a new syntax and a new standard library, without making it incompatible ever Y piece of Go code written to date? How could we avoid the "all" or nothing stand-off in which other languages place their users?

What if we could combine code written on Go 1.0 and a proposed GO 2.0 in one program using the package level as the Bounda Ry between language versions? Go 2.0 would is a new language, with a new standard library built upon a runtime shared between itself and go 1.0, thereby Allowing users to work outwards from their Go 2.0 package main to the limbs of their dependency graph, one package at a Time.

A Go 2.0 package would is able to call down to Go 1.0, but is not the other-to-be around. Go 2.0 types would be able to interoperate with Go 1.0 types, but go 1.0 types would be unaware of Go 2.0 constructed code . Perhaps calling from Go 2.0 to go 1.0 looks conceptually like using CGO to call C code, except without the overhead as bot H languages would is compiled to the same intermediary form.

The key is both  language versions would be compiled to a single intermediate representation, one tha T can represent the superset of both syntaxes. This has Been done before; In the first few versions of Go, C Code and Go code is compiled to an intermediate representation, Ken Thompson's Univers Al assembly language, then converted to machine code at link time. Now With keith Randall's SSA compiler, there is a single low level intermediate representation (similar to GCC ' s GIMP LE and LLVM ' s IR) That's describes all the things, the make Go programs Go1.

There is a strong precedent for this; The ~sun~ Oracle JVM. For more than a decade the JVM had hosted Byte-code that is not compiled from .java source file. Combined with a version of it gofix could automate some of the effort in migrating a package to Go 2.0 syntax, this Coul D be a plausible-introduce a new version of Go without abrogating the investment in code written for Go 1.0.

1. This also raises the possibility of developing and other language front-ends using the Go toolchain. If you are in what LLVM have done for projects like Pony, Crystal, and Rust, think of what a portable, cross platform, opt imising compiler, with user space concurrency built in, and written on Go, not C + +, would mean for language experimentatio N.