Why I like Go’s interfaces

You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!

When I hear people talk about Go, a lot of the discussions focus on its concurrency features. Whilst it has a good concurrency story, the language landscape is currently filled with languages that have an equally good or better concurrency story – F#, Erlang, Elixir, Clojure, etc…

Personally, what I found really interesting from my time with Go was how its interfaces work. In short, interfaces do not need to be explicitly implemented – i.e. no implement keyword. Instead, interfaces are satisfied implicitly.


Duck Typing

In dynamic languages such as Python, you have the concept of Duck Typing.

“if it looks like a duck and quacks like a duck, it’s a duck”

Suppose you have a say_quack  function in Python which expects its argument to have a quack  method. You can invoke the function with any object so long it has the quack  method.


Duck typing is convenient, but without a compiler to catch your mistakes you are trading a lot of safety for convenience.



What if there’s a way to get the best of both worlds?

In F#, this can be achieved through statically resolved type parameters:


But syntactically, statically resolved TP is kinda clunky and not the easiest to read. Go’s interfaces represent a more elegant solution in my view.


Implicitly Implemented Interface

In Go, suppose you have an interface for a Duck:


Any struct that has a Quack  method will implement the Duck  interface implicitly and can be used as a Duck.


(try it yourself here)

If you have another struct, Dog, which doesn’t have a Quack  method and you tried to use it as a Duck  then you’ll get a compile time error:


(try it yourself here)

so there, the convenience of duck typing with the safety of static checking!



Beyond Convenience

The design for Go’s interface stems from the observation that patterns and abstractions only become apparent after we’ve seen it a few times.

So rather than locking us in with abstractions at the start of a project when we’re at the point of our greatest ignorance, we can define these abstractions as and when they become apparent to us.

When you create a new interface, you don’t have to go back and tag every implementation, which sometimes might not be possible if the implementation is owned by a 3rd party.

This makes Go interfaces incredibly cheap, and encourages you to create very granular, precise interface definitions.


All and all, even though I don’t enjoy writing code in Go (as you tend to write imperative style of code), I think there are some very interesting ideas and lessons to take from the language.

It’s also a very relevant language of our time, with some important products (ahem, Docker) having been written in Go.

It’s a very small language still, and its website does a good job in helping you get started. Take a tour of Go if you’re interested in learning more about the language.



Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter

Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.

Skill up your serverless game with this hands-on workshop.

My 4-week Production-Ready Serverless online workshop is back!

This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.

We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.

If you enrol now you can also get 15% OFF with the promo code “yanprs15”.

Enrol now and SAVE 15%.

Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.

Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!

Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!