BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Go Language at 13 Years: Ecosystem, Evolution, and Future in Conversation with Steve Francia

Go Language at 13 Years: Ecosystem, Evolution, and Future in Conversation with Steve Francia

This item in japanese

Key Takeaways

  • Go’s simplicity allows you to quickly get started using it—you can digest the whole spec in just one afternoon.
  • The author considers Go to be one of the best modern languages of today (together with Dart + Flutter and Rust).
  • Go’s future is shaped by its open-source community which discusses and debates on all feature proposals. Unless a clear consensus is reached, the feature won’t be implemented.
  • The community’s size doubles around every 18 months.
  • Initially, the base of adopters was coming from dynamic languages like python or ruby, now as the language has matured Java, .NET, and C++ programmers have started adopting it as well.
  • In a challenging year, the community adapted to support each other, multiple meetups appeared, and new resources.

The history of programming languages went in one direction and one direction only; with each new language, things became more complex and more abstract. Then, just a few years over a decade ago, Go got started at google. And programming languages went the other way, put a bet on simplicity and things well crafted. That recipe is kept to the day and you can say that it can start straight away writing Go code without too much of a hurdle. That’s impressive when you just think that most of the popular and reliable pieces of modern software are written in Go—Docker, Kubernetes, Prometheus, and the list can continue. To understand where Go is coming from and more importantly where it is going, InfoQ reached out to Steve Francia, a core member of the Go programming language team at Google responsible for strategy and product.

InfoQ: Thank you for taking the time to answer a couple of questions from our readers. Can we start by asking you to introduce yourselves and describe your role and day-to-day job at Google?

Steve Francia: I am Steve Francia, a core member of the Go programming language team at Google responsible for product and strategy.

InfoQ: You have credited technical challenges and engineering challenges as the sparks that ignited Go thirteen years ago. Was there anything else? What were the official programming languages at Google then, and what was missing?

Francia: The primary motivation for creating Go was the recognition that our systems have grown in complexity. To keep up with exponential "Google scale" growth, complex systems were designed to address our needs. Over time new complex systems were built on top of these foundational systems/libraries and languages. People too often don’t think of the hidden costs of complexity. The truth is that code is read many more times than it is written. Team velocity is significantly burdened by complexity. In contrast, Go is simple. It takes an afternoon to learn. The code is very straightforward and readable. This simplicity empowers teams to collaborate in ways never before possible.

InfoQ: How did it all start? Was it a top-down request, (management asked for a language to address the needs), or was it bottom-up? The famous 20% of innovation from Google? Engineers doing what they do best -- solving problems?

Francia: Nobody ever asked for Go. It wasn’t really a 20% project. It was a conversation that led to a research project that gained traction and was adopted wider than anyone imagined. Of course, there was interest across Google from up and down the chain in finding ways to reduce complexity and increase productivity.

InfoQ: A saying in the start-up world is if you aren’t ashamed of your product on the day of the launch, you are probably too late. Go went public in 2011 when support for it was added to Google App Engine and YouTube started using Vitess. Was Go production-ready at launch or did people struggle to build things with it?

Francia: Go launched at the right time for Go. There was a lot of the foundation that was right, but there is a lot more in Go today that wasn’t in the early releases -- which is common in open source. Most obviously, there was no "go" command, so things that Go does so naturally today like "go build" were much harder in the earlier days.

The biggest advantage of releasing early was that it enabled the community to participate in the design process of Go. Major contributions that were a big part of Go’s success were provided by the community.

Our very first public releases of Go were production-ready in the sense that programs built with Go were performant and stable in production, but the Go authoring experience was still missing a lot of polish that the Go team and community were able to subsequently shape together.

InfoQ: Looking back, what was the most technical problem that you needed to address while building Go?

Francia: This is a hard one. It kind of implies that we’ve finished Go. I think there have been many "hardest" technical problems the Go project has addressed over the years and we are continuing to address very challenging technical issues. We are currently working on adding generics support to Go. Adding generics is a challenging task on its own, but we also want it to still feel like Go, meaning that using generics increases readability. That’s a very hard thing to do and something some of our key people have been thinking about for more than 10 years.

Over the past few years, we addressed some of the largest challenges regarding how 1dependencies are managed. We added module support to Go without introducing diamond dependencies or dependency hell, which no language has done before.

Another set of challenges is Go’s history of consistent performance improvements in each release. One way this has manifested is in the reduction in garbage-collection pause latency from seconds to milliseconds to microseconds. This has been transformative for Go and critical for its success in services.

InfoQ: If you would have to restart Go’s implementation, what would you do differently? Why?

Francia: With the advantage of hindsight, and as someone who has helped shape Go today, but wasn’t around for the first few years, I honestly would change very little. It’s a beautiful, well thought out language, and while it isn’t perfect, it’s very nice to use.

There are a few small tweaks that I wish we’d made, but to discuss them would put too big of a spotlight on really trivial things. Instead, if we could do it all over again, I wish we’d made the same mistakes, only sooner. Go is growing very fast, around every 18 months the Go user base doubles in size. This means that a change made today vs. five years ago impacts around 10 times as many people.

The dependency management Go has today is amazing, but it arrived maybe five years later than it should have. This delay made an already hard problem much harder and caused undue stress on the community as a result.

Similarly, the big language change we are working on now is generics. It will impact the community in a significant way. If we could do it all over again, with the hindsight of understanding how important this feature would be, I wish we would have started work in earnest on it maybe seven years earlier.

InfoQ: What does the Go programming language still lack?

Francia: As a language, generics are really the only major feature we’re missing and as I said earlier, we are currently focused on it. There is a playground available where you can use the prototype language feature today and give feedback.

Beyond this, most of the work to be done is refinements and polish, largely in the space around the language itself. For tooling, we have plans to improve the authoring, releasing, and editing experience. We are also working on helping people make better decisions about their dependencies.

InfoQ: Go was started at Google, but it is open-source now. Who’s calling the shots these days on what will be implemented?

Francia: In November 2020, Go celebrated 11 years of open source. Go has a well-defined proposal process that determines the entire direction of the project. Ideas and experiences come from everywhere -- every corner of the community. They are posted to the project on Github as proposals. From there the community weighs in on how they feel about the proposal and help to refine the idea further. The proposal committee meets weekly to review the open proposals. Currently, there are six committee members, four of whom are Googlers. This weekly meeting is mostly "gardening," the decisions almost always happen from the community discussions on the proposal issues themselves. Unless the issue discussion has a clear consensus of yes, the proposal is declined. By design and intent, changes to Go happen slowly and deliberately in the open. The process is designed to reinforce this.

InfoQ: How did Go’s ecosystem evolve with its increasing popularity? Go was mainly focused on networking and infrastructure at first. How did its usage evolve over the years?

Francia: One of the fascinating things about Go is how its journey took the project on a very different path than the founders had initially planned. They began Go with the intent of building a replacement for the popular high-performance server-side programming languages, which at the time were Java and C++. The founders thought that a simpler language could dramatically increase productivity for this class of developers while retaining performance.

While Go made some inroads with Java and C++ engineers, most of Go’s early adoption came from dynamic language programmers, coming from languages like Python, Javascript, Ruby, and PHP. It turns out that Go initially appealed far more to the dynamic class of language who saw an opportunity to retain productivity while dramatically increasing performance.

As Go and its ecosystem has matured, Go’s adoption has extended into the enterprise, and the initial audience of Java, C++, and C# engineers have accelerated their adoption of Go.

One of Go’s distinguishing features is that with a small language, most of the innovation happens in the ecosystem. We are consistently surprised by the creative and diverse directions that the community is taking Go. Go’s strength is still the cloud/server applications that Go is such a good fit for, but it turns out that Go is a really good fit for a lot of other types of applications as well. DevOps/SRE, CLI, web applications, and data processing have all taken to Go. Now we are seeing Go used for microcontrollers, robotics, gaming, and more.

InfoQ: Kubernetes, Docker, and Prometheus are all written in Go. Are there any other tools written in the language?

Francia: There are far too many tools to list here. Some of the more popular tools I use regularly are:

  • Hugo, a static site generator (which I created many years ago).
  • Syncthing, a distributed sync tool (think Dropbox/ Google drive, but without the server).
  • Istio, a service mesh
  • Terraform, infrastructure as code
  • InfluxDB, time-series database

A more extensive list can be found on Awesome Go.

InfoQ: Go is highly efficient and reliable when it comes to networking and systems programming, but what would be a space where Go wouldn’t fit?

Francia: Speaking for myself, I think there are only three modern languages today. Each was thoughtfully designed to address different shortcomings of prior generation languages, resulting in each excelling at largely different things and complimenting the others well. Here’s how I see the three languages:

  • Go is a good default language. It’s ideal for systems, servers, APIs, daemons, databases, websites, tools, etc. Go strikes the critical balance of performance and developer productivity.
  • Dart + Flutter for GUI based applications (mobile + desktop). Flutter has delivered well on the idea of writing one client application that works in multiple OSs and formats.
  • Rust for when you need fine control. Low level, kernel type stuff. Rust provides greater precision but with the cost of increased complexity. There are times when this tradeoff makes sense, and when it does, Rust is a great choice.

I think the majority of "modern" workloads over the next 10+ years will be written in one of these languages. Of course, there will always be legacy workloads that need to be supported, so please don’t read this as suggesting any language’s demise. And there are definitely areas where niche languages like R, SQL, and even Javascript, have a role to play.

InfoQ: Steve, I remember attending a conference a couple of years back in Budapest where you held a workshop about using Go. I had the feeling that you would recommend Go more to your enemies than to your friends -- why was that?

Francia: That was a great conference and my first time in Budapest. I’ve been back a few times since, it’s one of my favorite cities, such charm.

Many years ago now, I was working for MongoDB. My role there was leading the developer experience team which meant I was responsible for everything that touched our users. This included documentation, websites, developer relations, the MongoDB interface, and designing and engineering our integrations with languages and frameworks. It was a very broad and challenging role that required my team to write in over 10 different programming languages (and several human languages as well). I had used many languages myself over my career up to that point and made it a goal of being able to contribute to each of our languages. At the time I considered myself a polyglot and reveled in this opportunity to extend my experience and learn about these different languages.

At first, we focused on supporting the most popular languages, while I kept looking for what "the next language" might be. My first "next language" that I learned was Scala, thanks to Martin Odersky’s free online course in Scala. I enjoyed learning the language and kept searching. The next language I tried was Go. I fell in love. It was like someone designed a language just for me. I spent a lot of my free time, mostly 3+ hours a day on a train commuting to Manhattan, writing Go software. This is where Hugo, Cobra, Viper, Afero, and many other libraries and applications were born.

In the process, I learned I wasn’t a polyglot, I just hadn’t found my language yet. Since the moment I first used Go, I’ve immersed myself in the Go community and ecosystem, giving trainings around the world, speaking at many conferences, and organizing several events. I’ve spent the last seven years telling anyone who will listen about Go and along the way I somehow convinced the Go team and Google to let me join them. Beyond this, I’ve also helped countless others tell their stories, many of which are on Go.dev.

InfoQ: Go is 13 years old, so a teenager. What do you think about it? Is it the reliable type making the life of its users easier or still rebellious and moody, making it tricky to work with?

Francia: As a user, I think Go has never been better. The migration to modules happened quite smoothly. Go is very stable and its performance keeps getting better. The Go tooling also keeps getting better and better. Go.dev is a great one-stop resource, centralizing all the end users’ references, tutorials, documentation, and libraries from the entire community in one place. I might be biased, but as a Go user first, long before joining the Go team, I’m very happy with where Go is now and where we’re going.

InfoQ: What would you recommend as a toolbox for Go development?

Francia: One of the great things about Go is that it really meets you where you are. Go development is pretty much identical on Mac, Linux, or Windows, and Go’s cross-compilation makes it trivial to build for any arch and OS. With the introduction to the gopls language server, all editors and IDEs have a great experience writing Go. The Go tooling that ships as part of the Go distribution contains everything a developer needs to get started with the language.

I split my time between the three OSs, though I mostly develop on Windows using either VSCodium or Vim. I use the Cobra tool and library a lot, but my personal use of Go these days is mostly building little CLI apps and utilities to automate or streamline tasks so it fits well.

InfoQ: How steep is the learning curve for somebody starting from scratch with Go? What would your recommendations for a greenhorn be?

Francia: As I mentioned earlier, one of Go’s biggest strengths is how easy it is to get started. People are often shocked, but it’s really true -- you can read and digest the entire Go spec in an afternoon. You can learn Go in a weekend. Within a couple of weeks, you can be proficient in writing Go. Some are even faster than this. If you come to the language with the experience of a few other languages, you can pick up Go very quickly.

When we meet with companies that have adopted Go, this is one of the most consistent things they tell us. Go is just so easy to pick up.

InfoQ: What would be the prerequisites for a Go newb?

Francia: Honestly, just time and interest. Go is for everyone. There are some great getting started resources on go.dev curated from across the community.

InfoQ: Go’s evolution was surprising for everybody, including yourselves. Where do you see Go in the next decade?

Francia: If we look across the history of computer languages, the vast majority of the mainstream languages hit their stride between 15–20 years in. This is true for Java, Python, Ruby, JavaScript, and many others. In the 13 years since its inception, Go has established a great foundation and is becoming a mainstream language. Go has distinguished itself as simultaneously providing high performance and high developer productivity.

Over the next 10 years, the massive shift towards cloud computing will only continue to accelerate. Companies want to reduce their time to market, decrease their operating costs, and increase their security. The first phase of this migration will largely be migrating their existing workloads to the cloud. Go has a key supporting role to play here providing API bridging to enable "legacy" workloads to run on cloud services. The second, much more significant phase, will be the industry shifting to take advantage of the unique cloud offerings, increasingly moving to cloud-native application development. In these cases, Go is the clear choice.

All cloud providers are writing their critical infrastructure in Go. As companies look to modernize, what company wouldn’t want to use a safe and secure language, battle-tested over decades of critical workloads from some of the world’s largest companies, a language that will both reduce development costs and dramatically reduce their operating costs? In short, Go will be synonymous with cloud development, and cloud development will grow to be the overwhelmingly largest segment of the industry.

InfoQ: What should I have asked you but didn’t?

Francia: It is impossible to talk about a language and not talk about its community. In a very real sense, Go exists because of the millions of people around the world writing in Go. The Go community is strong, welcoming, and diverse. This year, like everyone, the Go community had to adapt, and adapt it did. All around the world, Gophers came together and helped each other. 30 (virtual) conferences were held. Hundreds of meetups (mostly virtual) and significant growth in participation on /r/golang and Gopher slack. Two noteworthy new community-led programs were launched to help new Gophers play-with-go.dev and mentoring.gobridge.org.

We are grateful for all of the Gophers around the world who are contributing to the thriving ecosystem that is Go and look forward to the bright future of Go together.

About the Interviewee

Over the past 25 years, Steve Francia has built some of the most innovative and successful technologies and companies which have become the foundation of cloud computing, embraced by enterprises and developers all over the world. He is currently product and strategy lead for the Go Programming Language at Google. Previously, he held executive/director roles at Docker, MongoDB, and the Drupal Association leading engineering, product, developer relations, operations, and open source. Steve is the creator of Hugo, Cobra, Viper, spf13-vim, and many additional open-source projects, and he has the unique distinction of leading five of the world’s largest open-source projects. He is a published author, speaker, developer, mentor, and above all, a father of four. Outside of technology, Steve likes photography, travel, skateboarding, punk rock, and dystopian films.

Rate this Article

Adoption
Style

BT