Has the Go Language Become Cloud Native?

In this episode of The New Stack at Scale, we explore the ways in which today’s developers must think when working in the cloud, the differences in static and dynamic programming languages, and how the Go programming language has found its niche in today’s container-based infrastructures.

When it comes to the languages today’s applications are built on, there’s no end to the debate between whether to choose a static or dynamic language. JavaScript and Python are two of the more common dynamic languages, allowing for flexibility for the developer. Fulton explained they accomplish this by the fact that, “They bind their dependencies at the last possible moment.”

On the other hand, Go is a static language demands developers be very clear when writing their code. When the code is run through a compiler, the resulting program spends less time spent in limbo waiting for dependencies, as it already has what it needs from the dependencies and libraries within a singular binary package.

Containers work with single binary packages extremely well, though working with containers in Go presents a unique set of challenges not seen in other programming languages. “The challenge is kind of a funny one because it still solves the use case of what it was designed for originally, by the folks at Google. But it’s one of those use cases because it does build in the libraries… It solves their use case, and their use case is unlike a lot of other folks’ use case or Linux distributions’ use cases,” said Batts.

Sponsor Note

New Relic is a software analytics company that makes sense of billions of metrics across millions of apps. We help the people who build modern software understand the stories their data is trying to tell them.

That being said, Go still faces challenges in the broader cloud-based ecosystem. By and large many of today’s businesses simply don’t have the toolkits that Google has in place for working with Go. Instead, they rely on a more stasis approach for their infrastructure, which Haupt warned about: “It’s extraordinarily common for applications of any size to want to not reinvent the wheel, and take advantage of all the great work…Vendoring is kind of freezing your dependencies: taking those things, grabbing a copy of them at the current version that works for you, and setting them aside and only referring to those.”