Fullpipe
Fullpipe (source: jklugiewicz via Pixabay)

Go 1.8 is due to be released next month and it’s slated to have several new features, including:

Which of these new features will have the most impact probably depends on how you and your development team use Go. Since Go 1.0 released in 2012, its emphasis on simplicity, concurrency, and built-in support has kept its popularity pointed up and to the right, so the answers to “What is Go good for?” keep multiplying.

Here I’ll offer some thoughts on a few things from the upcoming release and elsewhere in the Go world that have caught my eye recently. It’s hardly an exhaustive list, so let me know what else you think is going to be important in Go for 2017.

Go’s super deployability + plugins = containers, anyone?

The 1.8 release planned for next month has several folks I’ve talked with wondering how the addition of dynamic plugins—for loading shared libraries with code that wasn’t part of the program when it was compiled—will affect things like containers. Dynamic plugins should make it simpler to use high-concurrency microservices in containers. You’ll be able to easily load plugins as external processes, with all the added benefits of microservices in containers: protecting your main process from crashes and not having anything messing around in your memory space. Dynamic support for plugins should really be a boon for using containers in Go.

For some expert live Go training, sign up for Go Beyond the Basics.

Cross-platform support will keep pulling in developers

In the 7 years since Go was open-sourced, it has been adopted across the globe. Daniel Whitenack, a data scientist and engineer who maintains the Go kernel for Jupyter, told me he recently gave a data science and Go training in Siberia, (yes, Siberia! And, yes data science and Go—more on that in a bit . . .) and “was amazed to see how vibrant and active the Go community was there.” Another big reason folks will continue to adopt Go for their projects is cross compilation, which, as several Go experts have explained, got even easier with the 1.5 release. Developers from other languages such as Python should find the ability to build a bundled, ready-to-deploy application for multiple operating systems with no VM on target platforms a key draw for working in Go.

Pair this cross-platform support with projected 15% speed improvements in compile time in the 1.8 release, and you can see why Go is a favorite language for startups.

Interested in the basics of Go? Check out the Go Fundamentals Learning Path for guidance from O’Reilly experts to get you started.

A Go interpreter is in the works; goodbye Read-Eval-Print-Loop

Some really smart people are working on a Go Interpreter, and I will definitely be watching this. As many of you know too well, there are several Read-Eval-Print-Loop (REPL) solutions out there that can evaluate expressions and make sure your code works as expected, but these methods often mean tolerating inconvenient caveats, or slogging through several to find the one that fits your use case. A robust, consistent interpreter would be great, and as soon as I hear more, I’ll let you know.

Working with Go complexities in your development? Watch the Intermediate Go video training from O’Reilly.

Serverless for Go - what will that look like?

Yes, there’s a lot of hype right now around serverless architecture, a.k.a. function as a service (FaaS). But sometimes where there’s smoke there’s fire, so what’s happening in the Go space around serverless? Could we see a serverless service with native support for Go this year?

AWS Lambda is the most well-known serverless provider, but Google also recently launched Google Cloud Functions. Both of these FaaS solutions let you run code without managing servers; your code is stored on a cluster of servers managed for you and run only when a triggering event calls it. AWS Lambda currently supports JavaScript, Python, and Java, plus you can launch Go, Ruby, and bash processes. Google Cloud Functions only supports JavaScript, but it seems likely that both Java and Python will soon be supported, too. A lot of IoT devices already make use of a serverless approach, and with Go’s growing adoption by startups, serverless seems a likely spot for growth, so I’m watching what develops to support Go in these serverless solutions.

There are already several frameworks that have Go support underway for AWS Lambdas:

  • λ Gordon - Create, wire and deploy AWS Lambdas using CloudFormation
  • Apex - Build, deploy, and manage AWS Lambda functions
  • Sparta - A Go framework for AWS Lambda microservices

There’s also an AWS Lambda alternative that supports Go:

  • Iron.io: Built on top of Docker and Go; language agnostic; supports Golang, Python, Ruby, PHP, and .NET

For more on serverless architecture, watch Mike Roberts’ keynote from the O’Reilly Software Architecture Conference in San Francisco: An Introduction to Serverless​.

Go for Data—no really!

I hinted at this at the beginning of this article: perhaps surprisingly, a lot of people are using Go for data science and machine learning. There’s some debate about whether this is a good fit, but based on things like the annual Advent Posts for Gopher Academy for December 2016, where you’ll note at least 4 of the 30 posts are on ML or distributed data processing of some kind, it’s happening.

My earlier point about Go’s easy deployability is probably one key reason data scientists are working with Go: they can more easily show their data models to others in a readable and productionable application. Pair this with the broad adoption of Go (as I mentioned earlier, its popularity is pointed up and to the right!), and you have data folks creating applications that “work and play well with others.” Any applications data scientists build in Go will speak the same language as the rest of the company, or at least fit very well with modern architectures.

For more on Go for data science, Daniel Whitenack has written an excellent overview that explains more about how it’s being used: Data Science Gophers.

Article image: Fullpipe (source: jklugiewicz via Pixabay).