If you haven’t been living under a rock, you’ll know that recently there is an uptake in popularity of “Functions as a service”. In the open source community, the OpenFaaS project from Alex Ellis has received good traction, and recently Amazon Lambda announced support for Go. These systems allow you to scale with demand, and execute your CLI programs via API.

Motivation behind Lambda/FaaS

Let’s call this for what it is - the whole “serverless” movement is marketing for cloud stacks like AWS, that allow you to hand over any server management to them, for, hopefully, a fraction of your income. In concrete terms, this means that AWS and similar solutions take your application, and take steps to run and scale it based on demand in their data centers.

Importing packages is an integral part of most programming languages today, and Go is no exception. Importing packages in Go is, for the most part, a simple process. For most people, the basics of importing is enough, however there are some pitfalls that can show up and it’s always good to be aware of them.

Reflection is the capability of a programming language to inspect data structures during runtime. When it comes to Go, this means that reflection can be used to traverse over public struct fields, retrieve information about tags of individual fields, and possibly other slightly more dangerous things.

Error handling in Go is uniquely designed to be explicit in the intent. You should return possible errors from functions and check/handle those returns. This, in contrast with other programming languages, might seem verbose and unfriendly, but it isn’t really so. Let’s go over some basic examples and move on to something less trivial.

Every day, or every few days at the least, somebody comes on /r/golang and asks something along the lines of “Which framework is the best?”. I think we should attempt to ask this question, at least in a way that’s easy to understand. You shouldn’t use a framework.

Writing elegant or readable code is a driving force for some programmers that have been around long enough to know that less code is usually better than more. We also know that less code is usually also less efficient than more, for various reasons. Depending on how you like your cat skinned, there are several ways to do things.