Goat: A Proposed ‘Extended Flavor’ of the Go Programming Language
The idea came in April. At the end of an hour-long discussion on Changelog’s “Go Time” podcast — in a segment called “unpopular opinions — software engineer Kris Brandow said offhandedly that “I think it’s time for Go to have a fork…
At the time the programming language’s core team had just added generics — a more flexible “unspecified” type for variables — which Brandow saw as a shift to “a more academic, research-style thing.” Brandow argued that there were unacknowledged fractures in Go’s community that needed recognition, “and then maybe more formal conversations. Because I feel like the community — we’re not all together right now, and I think we’re pretending that we are…. ”
The podcast then ended with the guests playfully brainstorming on possible names for a fork of Go — including Gone, NoGo, Stay, Goto, oG, Stop, and Go++ — or even worse, Go#.
In a later online poll, 34.8% of the 69 voters said they agreed with Brandow.
Not unpopular enough if you ask me 😤 https://t.co/jogg7pjJpY
— The Nuanced Writer (@skriptble) May 3, 2022
But 17,498 people had listened to the podcast — and one of them was backend architect Aviv Carmi, who took the idea and ran with it. He wrote three blog posts culminating with a proposal to bring experimental new features to Go in a separate fork (or “extended flavor”).
“This will allow keeping the language as it was originally designed,” Carmi wrote, “while allowing an extended flavor of the language to evolve.”
As the blog posts circulated on Reddit, Carmi also created a repository for the possible project on GitHub, where he’s been carefully watching the Issues folder for any incoming comments and suggestions. (Issues to date? 11 open, two closed…)
This may all ultimately amount to nothing more than online chatter — the blog posts, repository, and the end-of-episode commentary on an April podcast. But whatever happens, it shows a community in action — or at least a part of a community — feeling empowered enough to sound off and make dramatic suggestions about the future of their language. Conversations happen, discussions get fomented, everyone weighs in on which direction they think best supports the community…
So what exactly is it that Carmi is proposing?
A Flavor Called ‘Goat’
“I would have loved to see a compile time environment that mostly looks like Go, but allows developers to be a bit more expressive,” Carmi’s blog post series concludes, “to gain maintainability and runtime safety.”
For example, Carmi wants to add keyword-based modifiers for variable and function visibility (like the keywords “public” and “private” in Java) rather than following Go’s current practice of granting outside-of-package visibility to anything that starts with an uppercase letter. And Carmi also wants to see a syntax that supports enums — a kind of limited variable (found in other languages) with a pre-defined set of possible constant values.
His final blog post makes five more similarly thoughtful suggestions — but taken all together, Carmi wants to see the creation of a simple “extended flavor” of Go which he’s calling Goat.
When compiled, Goat code “will produce standard, compatible, and performant Go files that are fully compatible with any other Go project. This means they can import regular Go files but also be safely imported from any other Go file.” The actual implementation would “most likely be delivered as a code-generation tool or as a transpiler producing regular Go files,” according to the official GitHub repository for his idea.
And that page stresses that “Our basic rule is to not create fragmentations in Goat syntax.”
Carmi underscored that point in his first blog post, writing that if a fork or extended flavor happens, he hopes it shares Go’s original ecosystem — the same libraries and runtime environment — “to ensure we remain a single community with a single ecosystem, believing in the same core philosophy.” The repository also emphasizes that the proposed project would still be based “on the premise of keeping things simple” — something Carmi applauds in the way Go is today.
But in his online essay, Carmi writes that a commitment to simplicity at some point means you’re losing productivity. And yet, Carmi writes, most change proposals get rejected — which he believes signals a pent-up interest in experimenting with new features. (Carmi’s blog post notes the 118 open proposals in the “LanguageChange” folder of Go’s official repository on GitHub.)
Carmi acknowledged in a recent comment on Reddit that “Although the core Go team is strict when it comes to accepting proposals, they’re fairly open-minded in giving room for feedback and raising questions.” Yet as Reddit forums sent readers to Carmi’s blog posts, he tells me in an email interview, the handful of readers who clicked through to the repository “seem to be interested by the evolving spec” of his own extended flavor of Go.
And Carmi’s blog post argues it’s important to have a discussion about Go’s future. As “big companies, as well as small start-ups warmly adopt it, it’s getting as close as it can to being a standard language for cloud native systems.”
Finally, Carmi offers one more observation. His first blog post had lauded “What makes go the best language.” But he’d followed that with a post titled “We Need To Talk About The Bad Sides of Go” — and it was that post that got four times more traffic than any of the others.
Carmi calls it “By far the most successful blog post I’ve written.”
Focused on Improvement
So how would he characterize the reaction? The most important audience, Go’s core developer team, hasn’t responded to his posts, “and respectfully, I don’t expect one any time soon,” Carmi tells me, adding “They have a lot on their plate.” (The New Stack also reached out to a PR agency that works with the Go team, but the team was unavailable for comment.) Carmi believes his project needs to evolve much further before it’s worthy of attracting any serious attention.
And he wants to reassure the Go community that he’s solely focused on improvement. “I do not wish to write a new language,” Carmi adds in his email. “I wish to empower the existing one [and] provide Gophers with the ability to use an additional tool in a seamless way. Each Gopher will be free to choose if and when to use Goat and for the specific use cases it would serve best.”
He emphatically underscores the point. “I do wish to stress to Gophers that the essence of the Goat project is to empower the Go community.”
Carmi also feels there’s a precedent. In his blog post, he cites how Scala and Kotlin ultimately strengthened the community around the Java Virtual Machine. “All three languages contribute to a stronger, single community and gain stronger libraries and integrations.”
In our email interview, Carmi delved into a second example. “If you look at Typescript and what it has done for the Javascript community, it only made it stronger and provided engineers with a new, powerful tool they can use if and when they choose to. I would love Go to have something similar. To help many Gophers have the features they feel missing, and also allow Go itself to remain the same.”
So where are things now? “Currently the project is in the phase of designing the language specifications,” Carmi tells me in his email, pointing to those 11 open discussions in its GitHub repository, “Each concerning a different feature of the language which we haven’t decided how to finalize.
“Those who join the discussion now are the ones that are mostly interested in affecting the language spec.” But Carmi predicts more interest when there’s an actual new language to try.
And throughout his comments is a larger theme: the need to stay open to new ideas — and to discussions about them. Carmi tells me he’s very much aware of the protectiveness felt toward the language by some people in the Go community. He points to another Reddit discussion where a user asked why Go doesn’t currently support enums — a question was downvoted by 15% of the voters on Reddit.
Carmi had left his own comment in that discussion. “Many Gophers tend to have a bit of a sports fan mentality, in which everything that might be perceived as criticism is automatically downvoted by some…”
“A community that strives for best should always be open to raising questions and answering them.”
