Code Genealogy, Tooling Evolution and the Future of Go – InApps 2022

What paths will the Go programming language take? This question is posed to CoreOS CTO and Co-founder Brandon Philips, and DeferPanic Founder Ian Eyberg, at the start of this edition of InApps Analysts podcast, recorded at GopherCon yesterday.

For more episodes, check out the podcast section of InApps.

#52: Code Genealogy, Tooling Evolution and the Future of Go

Listen to all TNS podcasts on Simplecast.

This podcast is also available on YouTube.

Go is the modern systems language. Period. It has a heritage as a systems language and that history will continue to serve as the basis for its future.

“We’re talking about systems that aren’t writing kernels — not writing underlying, low-level bits that are talking directly to hardware — but systems that are interacting across a data center or across the Internet,” says Brandon.

“The cool thing is,” says Brandon, “it’s a piece of technology that’s enabling a lot of interesting research and development in those areas. So you’re seeing time-series databases being built, you’re seeing these consistent databases being built, schedulers, things that talk to and configure network fabric.”

Ian says that Go has a consistent syntax that’s easy to learn, that he can read it in one environment and then another, and see the same style. Upon learning it, one can read it anywhere, in easy-to-understand terms, says Ian, whereas Erlang, for example, is a language that has some similarities to Go, but it is hard for people to understand what they are looking at when they see it.

People other than those on the Golang core team are able to import external packages, an idea that Brandon deems to be good, interesting, and well-thought-out. As the Go language and tooling matures, the language itself can remain lean.

According to Ian, packaging in general has become a contentious issue.

As have generics, too, suggests Alex.

“I think a small minority of people have a problem with [generics],” says Ian. “The people that have a problem with a lack of it — they’re so used to a different style of programming from other languages that allow them to mix and match their code freely, even when it might not be the best idea to do that.” He also says that JavaScript, Ruby and other languages have problems with it, too. Because it’s a fairly widespread issue, deep concern about it within the Go community isn’t warranted.

Brandon says that, for CoreOS, the hardest thing in Go is the dependency management. “It replicates every time CoreOS creates a new open source project. We have to bundle those things and vendor those things all over again.”

Despite a continuing need for better tooling, Brandon sees an encouraging trend. “Over the last year we’ve gone through a number of different tools. We wrote a vendoring tool, other vendoring tools have come out, and everyone’s coalescing around a single set of patterns, and the Go core team is adopting these patterns into the actual mainline.”

However, Alex observes, the tools have to be all-encompassing. Brandon agrees, adding, “It is not just about taking source code and generating machine code.”

Ian is convinced that Go will overtake Java in the long run, perhaps within a couple of years. But, some human compromises remain, including different dialects, “no matter how much the core team doesn’t like that idea,” says Ian. “I’ve already seen examples out in the wild.”

Finally, the core team released Go to the community, and dealing with the aftermath might be the hardest part, as it becomes essential to work with a community that’s moving from implicit to explicit trust.

CoreOS is a sponsor of InApps.