This Week in Programming: GoLang 2.0 and How To Handle Breaking Changes
This week, GoLang principal engineer Ian Lance Taylor offered his musings about moving from Go 1 to Go 2, along the way examining the growth of some other mainstay languages and how they handled (or didn’t) breaking changes and the like.
While GoLang devotees may be more interested in the specifics, it is this contextual analysis of language growth that I find particularly interesting — and I use the word “growth” intentionally, as it seems that, depending on the culture and even the particular procedures used to create a language, a language can become what it is outside of what some community members may intend. Indeed, we’ve watched over the last year as members of the Go community debated, disagreed, and eventually moved on as the vgo versioning system was put in place. Similarly, the Rust community has experienced turmoil in its RFC process and the transition from idea to a discussion to implementation. In both cases, we’ve seen members of each community attempt to analyze and find a clear, logical path to follow forward.
Today, we look at another such attempt, in Taylor’s proposal for moving from Go 1 to Go 2.
Programming is like magic. You write very specific instructions in arcane languages to invoke commands, and if you get it even a little bit wrong you risk unleashing demons and destroying everything.
— Artemis (Diana) (@artemis_134) June 23, 2018
In his proposal, Taylor briefly examines how C, C++, Java, Python, and Perl handled various transitions in an attempt to create a “proposal for how to make incompatible changes from Go 1 to Go 2 while breaking as little as possible.”
As background, the Go language and standard libraries are covered by the Go 1 compatibility guarantee, which states that “programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification.” Taylor explains that, “among the goals for the Go 2 process is to consider changes to the language and standard libraries that will break the guarantee” and that “since Go is used in a distributed open source environment, we cannot rely on a flag day. We must permit the interoperation of different packages written using different versions of Go.”
For each language examined, Taylor offers some lessons learned as guidance for moving forward with Go 2. For example, C shows that “backward compatibility matters,” but “breaking compatibility in small ways is OK, as long as people can spot the breakages through compiler options or compiler errors.” Java, meanwhile, shows that language designers should “be aware of how compatibility issues may restrict future changes.” And Python’s incongruous transition from Python 2 to Python 3 exemplifies the importance of backward compatibility.
What lessons did we learn from Perl? “Don’t be Perl 6,” Taylor writes, also noting the importance of setting and meeting deadlines (Perl 6 took a mere 15 years) and not changing “everything at once.”
Taylor’s post is a perfect example of one taking the advice of the eternally misquoted aphorism, “Those who cannot remember the past are condemned to repeat it.” By examination of the past, perhaps Go will succeed in avoiding such condemnation.
And again, it’s less the specifics, which Taylor does address, but rather the broad strokes of the attempt that seem most interesting. “If the above process works as planned, then in an important sense there never will be a Go 2,” Taylor summarizes. “Or, to put it a different way, we will slowly transition to a new language and library features. We could at any point during the transition decide that now we are Go 2, which might be good marketing. Or we could just skip it (there has never been a C 2.0, why have a Go 2.0?).”
So, what after such detailed historical analysis of language development, is Taylor’s conclusion?
“A real Go 2 would, perhaps unsurprisingly, be harmful.”
This Week in Programming
- Go Gets Tiny: Continuing with the GoLang thread this week, we couldn’t help but notice the mention of TinyGo, a Go compiler for microcontrollers and small systems with a single processor core, based on LLVM. According to the repository description on GitHub, TinyGo is similar to emgo but keeps “the Go memory model (which implies garbage collection of some sort).” It also uses “LLVM internally instead of emitting C, which hopefully leads to smaller and more efficient code and certainly leads to more flexibility.” Why make a Go compiler for microcontrollers, you might ask? “If Python can run on microcontrollers, then certainly Go should be able to and run on even lower level micros,” the project’s creator writes.
- GitLab 11.4 Adds Merge Request Reviews & More: Moving on from GoLang, GitLab this week announced GitLab 11.4 with Merge Request Reviews and Feature Flags, which it says will make code reviews more efficient with Merge Request Reviews and a file tree for diffs. The Feature Flags, a feature toggle system is being introduced in alpha and Auto DevOps and CI are getting PostgreSQL migrations and timed incremental rollout. The Merge Request Reviews feature will let reviewers “enter multiple comments on the code or merge request and then finalize them in one batch.”
In the Hands of the Demo Gods, as seen today on @devopsdotcom #humor, #satire, #parody, #demohell pic.twitter.com/bnPFox96Q6
— Bob Reselman (@reselbob) October 24, 2018
- GitHub Gets FedRAMP Authorized: Nevermind that whole incident the company had this week, GitHub announced that GitHub Business Cloud is FedRAMP authorized now, via “the FedRAMP Tailored baseline of security controls.” This basically means that government users can continue to use GitHub and know that their asses are covered — they followed the guidelines and used a service that is certified to meet the “baseline of security standards set by our US federal government partners.”
- OpenJDK May Head to GitHub: InfoWorld reports this week that Java SE’s OpenJDK could be headed to GitHub in “a move that could aid Java developers” by providing access to a number of automation tools and “familiar resources being used to develop the JDK itself.” According to the article, the move is part of Project Skara, “which is an ongoing effort to examine new infrastructure for OpenJDK, [and] could have the repos moving over to Git-based repos, including possibly GitHub or other host.” In terms of timing, the move could happen “in the timeframe of JDK 12, which is due in March 2019, or possibly afterward.”
- Node 11 Arrives: According to JAXEnter, Node.js 11 is all about improving internals, with the two most noteworthy features being the abandonment of FreeBSD 10 and the rescheduling of interval timers “even if the previous interval threw an error.” The Node v11.0.0 announcement also notes that Node.js 10.x will become the latest long-term support (LTS) release, which “basically means it will be ready to be used in production and by applications that need to scale.” JAXEnter also asks if “Node.js’ days numbered?” noting the “need to address the elephant in the room” — Node.js creator Ryan Dahl’s recent announcement of “a secure TypeScript run-time on V8 called Deno” which is said to address the security issues that Dahl highlights “as one of his major regrets about [Node.js].”
- GNU’s Kind Communication Guidelines: Finally this week, rounding out the topic of language development and the (often heated) debate inherent in that process, SDTimes offers a tale of how Richard Stallman released GNU Kind Communication Guidelines “in an effort to steer conversations in a kinder direction.” Stallman’s post notes that “People are sometimes discouraged from participating in GNU development because of certain patterns of communication that strike them as unfriendly, unwelcoming, rejecting, or harsh. This discouragement particularly affects members of disprivileged demographics, but it is not limited to them. Therefore, we ask all contributors to make a conscious effort, in GNU Project discussions, to communicate in ways that avoid that outcome—to avoid practices that will predictably and unnecessarily risk putting some contributors off.”
The cloud has truly revolutionized computing. Now, instead of constantly asking, "Why doesn't this code work on my machine," we can spend that time wondering, "Which networking configuration is blocking me from uploading this code so that it will fail on someone else's server?"
— Vicki (@vboykis) October 25, 2018