I'm gonna be doing a live-stream this Friday on Twitch. It will be just myself, sitting at the desk you see in the photo above, talking about building stuff on AWS for about 90 minutes.

I've been thinking of doing something like this for a while. Not a podcast, not a radio show, but a broadcast where I work my way through learning something new in front of an audience.

For this first show, I'm gonna keep it super simple and entry level. We will be discussing Go, the programming language I've been trying to learn over this past year, and how to get Go running on AWS Lambda. I will also get into the developer experience for the above and some useful tips and tricks you might not know about!

This is an experiment! Don't expect a nicely polished scene with neon rope lights in the background and a fake plant sitting on top of a brand new Ikea Kalax shelf. That's not this show. I'll do my best, and improve over time, and if it winds up being fun and useful, I may do it on a regular basis!

To tune in, mark your calendar for Friday, Feb 2, at 3:00pm ET, or just click this link to get a reminder.

I hope to see you there!

-m

I'm building a thing. I'll write more about that thing in the near future. But, in the meantime, I thought I'd write a little about one small other thing I learned along the way.

The thing I am building has two main components.

1. A back-end workflow that uses AWS Step Functions to periodically orchestrate fetching and processing some data before storing it in an Amazon DynamoDB table.
2. A front-end website built using Next.js that displays the data as a static website, hosted on AWS Amplify.

The front-end needs to be rebuilt whenever there is new data to display. With AWS Amplify, you can easily create a Webhook to invoke a new build. Here's how it works.

In my SAM template, I configure DynamoDB streams like this:

Then I need an AWS Lambda function to trigger off the DynamoDB stream. It's defined in my SAM template like this:

The function code itself is super simple. It just makes a POST request to the Webhook.

There is one little trick I am doing here you may have noticed. I am storing the Amplify Webhook URL in AWS Systems Manager Parameter Store and setting it as an environmental variable in my Lambda function. This way I don't have to hard-code anything into my SAM template.

AMPLIFY_WEBHOOK_URL: '{{resolve:ssm:/new-thing/amplify-webhook-url:1}}'

Now, whenever my State Machine runs, it updates DynamoDB, which triggers a Lambda, which tells Amplify to rebuild the site. Yay!

I had an interesting conversation at work today around package size limits for AWS Lambda and it got me thinking about a number of strategies for dealing with these limits.

The limits

First, here are the limits. As per the documentation, your Lambda function, including all its source code, layers, and any custom runtime must fit within the size limits listed below:

• In the AWS Console Editor - 3MB
• Zipped for direct upload - 50MB
• Unzipped (using an S3 bucket) - 250MB
• Container image - 10GB

How to deal with the limits

Here's a few ideas I came up with on how to deal with these limitations.

1. First, optimize the code as much as possible to shrink the dependency size and make sure you aren't importing unnecessary libraries. You can do this by building dependencies from source, and by making sure you are only importing the parts of the library you actually need vs. a global import.
2. Consider splitting the lambda into separate steps and use AWS Step Functions to orchestrate. For example, a Lambda that fetches data from MySQL using PyMySQL, and then another Lambda that processes that data using Pandas would mean your package size could be split across two separate functions, where each function only loads the libraries required.
3. Use a container - This will up the size limit to 10GB from 250MB. That's a big difference!
4. Use Amazon Elastic File System (EFS) - You will need a VPC and an EC2 instance to write the initial data to the EFS volume, but this configuration can give your Lambda plenty of room to breathe.

Wow, that title is a mouthful. Here's what it means:

• You can use AWS SAM to easily construct at Serverless Application on AWS where the AWS Lambda code is written in Go
• You can deploy your app to AWS from the CLI with sam deploy which is nice when you are building something on your own, or just getting started
• Once your project grows and begins to involve others, you will likely want to incorporate some kind of CI/CD pipeline
• AWS SAM Pipelines and GitHub Actions make this all work really nicely!
• These are my notes so far

An AWS SAM Pipeline consists of two major components:

1. The bootstrap command - This command ( sam pipeline bootstrap) needs to be done for each stage in your pipeline (test, prod, etc.). The end result is a handful of resources deployed in your AWS account that will be required by the pipeline itself. These are things like Roles, Policies and an Amazon S3 Bucket.
2. The init command - This command ( sam pipeline init ) will walk you through a little wizard to help craft a GitHub Action template. This file will appear in your repository at .github/workflows/pipeline.yml and contains all the configuration GitHub Actions will need to build, test and deploy your application whenever you push new changes to GitHub.

For my project I chose to use GitHub Actions for my CI/CD tooling, but you can choose from a number of other popular tools like Jenkins, GitLab or AWS CodePipeline. I really like GitHub Actions.

One thing I noticed was that the pipeline.yml file contained a number of fields that included my AWS account number and a few ARNs. In a private/corporate repository, this might be fine, but for my public repo, I chose to change these to use GitHub's repository variables. Here's what my final list of fields looked like:

Once you set these up, you just need to create the actual variables in the GitHub settings page for your repo.

Another issue I ran into was building a Go program with GitHub Actions wasn't working right out of the box. When I do a sam build and sam deploy from the command line, everything works just fine, but that's because I am building with the installation of Go on my laptop. On GitHub, it will need to have Go installed as part of the build process. The template I started with didn't know about this, so I had to modify it to look like this:

You can see here that instead of just doing sam build I first need to install Go and add it to the $PATH.

Once I made these changes and made sure all my variables and secrets were setup in the repo settings, I was able to push my code and watch it deploy to AWS.

This pipeline has a couple interesting ... features:

1. You can use feature branches like feature-new-gizmo to deploy from a separate feature branch. It will also clean these up as you delete old feature branches.
2. It has two stages for "testing" and "production." In this current setup, it will just deploy both of them on every new push to main. But, you can utilize GitHub Environments to add a manual intervention or approval step for the production branch.

Here's my demo application on GitHub including the SAM Pipeline.

That's it!

A while back I created a repo on GitHub that was simply the output of doing sam init and choosing the AWS Quick Start Template for a Hello World Example.

From there, I simplified the SAM template.yml file a little, restructured the folder where all my Go code lives, and added a .devcontainer file to help with getting things working on GitHub Codespaces.

To start a new project locally, all you need to do is the following:

> mkdir your-project
> cd your-project
> sam init

From here, choose option 2 "Custom Template Location" and enter the repository URL – https://github.com/go-micah/go-serverless-sam-template

All this does is it downloads the files to your local machine, without cloning the repo, to be used as a starting point for a new project.

Did you know you can easily create your own templates for AWS SAM? Nice!

While working on my chat-cli program, I realized that waiting for a response from Amazon Bedrock could take some time, depending on the nature of your prompt. To offer a better user experience, I looked into the InvokeModelWithResponseStream API method, which allows you to receive the response from Bedrock in chunks rather than all at once. This means you can begin to print out the response to the user as it arrives instead of just showing some equivalent of a spinning beach ball.

The problem was, I didn't really understand how to deal with the InvokeModelWithResponseStream in Go. I looked through the documentation and eventually figured out that it was leveraging Go's Channels feature, which I also didn't know much about.

It turns out that Go Channels, and Go Routines are pretty powerful and somewhat simple once you understand what's going on under the hood. I found a nice tutorial here, and here, and created my own playground to test things out on my own.

The way I understand this, Go Routines allow you to launch multiple non-blocking threads. This is nice, but it can be difficult to manage taking action on any of these threads when they are complete. To deal with that issue, there are Go Channels, which allow you to essentially send messages from one Go Routine to another.

In my sample code above, I am trying a few different approaches to calling a long running process. The first is a standard function call. Everything has to wait 10 seconds until that function is complete. The second is a started in a Go Routine, using the go syntax. This process is non-blocking, but if the program completes before this routine is done, we may not see its output. The third and fourth are Go Routines with a Go Channel. These allow us to launch non-blocking threads and send some output back to the main function once they are done.

For Bedrock's InvokeModelWithResponseStream API method it works pretty much the same.

First, you make the API call like this:

The response from this call will open a Go Channel, which you can react to in a loop like this:

In this code, we grab the Go Channel with stream.Events() and then in the loop we are capturing each event with the Go Channel syntax event := <- events. From here we are just testing to see if we have any new events before breaking out of the loop and closing the stream. If we have new events, we print them as they arrive. This winds up looking like a streaming response to the user, and is much better than waiting for the entire response to arrive!

In yesterday's post I talked about building an Amazon Bedrock powered CLI that allowed for an interactive chat. Below is more or less the code I started with to create the command line chat.

As you can see, there is an infinite loop nested within another infinite loop. One of my favorite aspects of Go is the for loop, which is the only kind of loop and used to create any kind of other loop. Loops!

The main function kicks off the first infinite for loop. This calls the stringPrompt function which starts the second infinite loop to capture input via stdin and waits for the user to press a \n. Then it returns the captured string to main which prints it out for demo purposes before it starts all over again.

chat-cli is a project I've been working on for the past couple months. It started out as a way to kick the tires on the now publicly available Amazon Bedrock service, and also as a way for me to learn a bit more about Go, and the AWS SDK for Go version 2. Since then, it has turned into a bit of an exploration into command line interface design, which is pretty interesting to me!

A CLI for LLMs (Micah's Version)

There are plenty of command line interfaces out there for working with large language models (LLMs). I especially like Simon Willison's llm project, which is built in Python and allows for a nice CLI to work with OpenAI LLMs and more. I drew a lot of inspiration from his project, and tried to create something similar for Amazon Bedrock.

In case you are unfamiliar, Amazon Bedrock is a new service from AWS that offers customers "The easiest way to build and scale generative AI applications with foundation models." It provides a unified API to access a growing list of foundation models without having to worry about provisioning infrastructure.

With Bedrock you can currently access foundation models from the following providers:

1. Titan from Amazon - (currently in preview).
2. Claude from Anthropic
3. Jurassic-2 from AI21 Labs
4. Command from Cohere
5. Stable Diffusion from Stability AI
6. Llama 2 from Meta - (coming soon)

Each model has different capabilities and nuances, which I'll describe in more detail below. Except for Stable Diffusion, these are all text based models, which allow you to have contextual conversations, summarize documents, generate new content like blogs or emails, and much, much more. Stable Diffusion allows for image generation from a text prompt.

Bedrock is a quickly growing service, and I'm keen to explore all its bells and whistles in the future, but for now, a simple command line program sounds like a nice way to get to know the service.

Getting Started

Initially my thought was to build a command line program that could talk to Anthropic's Claude in an interactive chat type of interface. Eventually I realized that what I really wanted was a program that could talk to any of the available models with a variety of interfaces and options.

To get started, I wrote a simple program in Go that created a chat style interaction at the prompt. The prompt would capture your input, mold it into the style expected by Claude, and send it up to Bedrock via the AWS SDK for Go.

Creating the chat loop was pretty simple. I wrote a function called stringPrompt that waits for input from the user. This gets called from the main program in an infinite loop, so once you send your prompt and get a response back from Bedrock, you wind up back at the prompt again, waiting for your next input.

Sending a prompt to Bedrock was also pretty trivial. The InvokeModel API method requires a small payload of info related to the model you want to invoke, and the details of your prompt. Within the AWS Console, you can try things out in the Bedrock Playground, which will generate a payload based on the model and settings you've chosen.

To keep things simple, I hard-coded most of the options based on my experience in the Bedrock Playground, and focused on designing the prompt format to look like what Claude was expecting. Claude has the idea of "Stop Words" which are used to give meaning to the conversation you are sending. For example, the default stop word is /n/nHuman: so your prompt needs to include this to separate your prompt from the responses from Claude.

There are lots of additional options and features for interacting with Claude, which you can read about on their website. I believe this is called "prompt engineering!"

It's alive!

Once I had this all wired up and working, I noticed a couple details.

1. Claude (or any model for that matter) only knows about whatever you send it each time. It doesn't have a persistent memory of your conversation. So while sending "Hi, My name is Micah" might result in "Hi, Micah." as a response from Claude, it won't remember that context the next time you send a message, unless you include it in the prompt.
2. The InvokeModel API is a synchronous request, which means you might wind up waiting for a good amount of time for a response to arrive, depending on the nature of your prompt.

To deal with #1 I investigated two different approaches. The first was to simply keep the running conversation in memory, stored as a string. While this could eventually run up against some hardware limits for the user, it likely will work for most conversation sessions. The second approach is to store the conversation transcript to disk and offer a way to load it back into memory. This seemed like a good idea when I started working on it, but in practice, I am unsure if it's really all that useful. Claude generates responses based on the text you send it, so it really becomes a matter of how much context you need to give it to get the kind of response you'd like to see. Remembering my name so that it can then use my name to generate a poem is nice, but it may not be important to remember every single interaction in the conversation. I'm still struggling to understand how to deal with this issue. Another side effect this brings up is that your conversation transcript will just grow and grow over time, which means you will begin to consume more and more input tokens, which have a limit, depending on which model you are using. This is especially problematic when you begin to want to include documents as part of the context as you need to carefully manage how many copies of the same text are sent to the LLM.

To deal with #2 I also investigated two different approaches. The simplest, dumbest solution was to add some kind of "wait state" indicator. Think spinning beach ball. For this, I found a nice Go package called "Spinner" which makes it really easy to add some kind of user feedback while you wait for a response. This is nice, but the user is still waiting for a response. The second approach was to implement the InvokeModelWithResponseStream API. This API appeared to do what I wanted by sending the response back in chunks rather than all at once, so that the user begins to see feedback right away. The only issue was it leveraged Go Channels, which was something I wasn't familiar with. So, I had to learn all about Go Channels.

Evolving the project

After getting things more or less working, I decided I wanted to make two major changes to progress the project forward.

So far my project was nothing more than a single main.go file. I knew I'd need to think a little more critically about the overall design of the software to accommodate the evolution of the project as I continued to experiment and try new things. For this, I turned to the very lovely Go packages Cobra and Viper. Cobra is a framework for building CLI tools in Go. It provides all the structure and tooling to set up a CLI program quickly, and allows you to easily add new commands, flags and all sort of options as the program grows over time. Viper is for dealing with configuration. The two packages work hand in hand and together allow me to not have to think too hard about how to build a CLI tool in 2023!

I spent a few hours re-factoring my project to work with Cobra and Viper and then began designing the overall interface. Through this process I realized a couple of things.

1. I wanted to offer multiple commands instead of just a chat program. So far I have created a chat command and a prompt command. The chat command does what I had already done, which is to put the user into an interactive chat session. The prompt command allows to user to simply send a single prompt.
2. I also realized that I really wanted to allow users to access any of the LLMs available in Bedrock. Cobra and Viper offered me an easy way to add feature flags, so I set about implementing the rest of the models I had available.

Not all LLMs are created equal

While Amazon Bedrock offers a unified API for interacting with LLMs, each LLM has its own unique characteristics. This means that a program that allows a user to interact with multiple LLMs will need to take these unique characteristics into account. For example, not all LLMs are capable of sending a streaming response. As well, each LLM has its own levers you can pull to adjust parameters like Temperature, Top P, or Top K. Since they are all a little different, I basically had to write unique types in Go for each one I wanted to support.

Beyond the various nuances of each LLM, Stable Diffusion is an entirely different animal. Instead of receiving a text based response, Stable Diffusion sends back image data. So, I had to think through how to deal with that, and save the results to disk. It wasn't too hard to figure out, but I did have to add logic to my code to give an error when the user was trying to do something that didn't make sense with Stable Diffusion, like starting an interactive chat session.

The current state of things and things to come

The program is now in what I would call a "working" state. You can clone the repository and compile it yourself and give it a go. Here is what you can currently do:

• You can enter an interactive chat session with Anthropic Claude.
• Within an interactive chat you can save and load your chat transcript to disk
• You can send a single prompt to Bedrock from the command line
• You can use the --model-id flag to select which supported LLM you wish to use
• You can use the --stream flag to get a streaming response from a supported model
• You can pipe a file in from stdin and combine with a prompt to do things like "explain this document to me"
• You can use Stable Diffusion from the command line to generate and save images to disk

I have a number of thoughts for future additions, but here are the near terms updates I plan to make:

• Ability to send a source image to Stable Diffusion
• Ability to save settings to a configuration file
• Un-hard-code all the LLM settings and create flags for each of them
• Implement additional functionality available through the SDK like listing of available models
• Setting up a documentation website for the project
• Figure out how to sign binaries for easy install

Help!

Overall this has been a fun project. I've learned quite a bit about Generative AI, Large Language Models, Foundation Models, and have had some fun learning more about Go and building command line interfaces. I'd love some help! If you'd like to try chat-cli on your own, contribute to the code, suggest ideas or comment on my coding skills, please feel free to do so right here.

I spent some time this week thinking about deploying Go programs and decided to learn how to containerize Go and in that process also decided to take a look at other ways to run Go on AWS. It turns out there are many options.

When I think about compute, there's basically three main categories of how I can run my code:

1. On a server
2. On a container, on one of the many ways to run containers, including on servers
3. On AWS Lambda

In my second post I talked briefly about running Go on AWS Lambda. I got it working pretty quickly, and it's likely a topic I'll come back to in more detail as I progress with the language. But, serverless compute isn't always the right choice, and so I thought I'd have a look at containerizing a Go program. (Interestingly, you can run a container on AWS Lambda--something I'm sure to experiment with in the future.)

Containerizing a Go program is pretty simple. I created a basic hello-docker repository and added the following code:

package main

import (
	"fmt"
	"net/http"
)

func hello(w http.ResponseWriter, req *http.Request) {

	fmt.Fprintf(w, "Hello, Docker.\n")
}

func main() {

	http.HandleFunc("/", hello)

	http.ListenAndServe(":3000", nil)
}

This is a super simple program that creates a web server using Go's net/http package found in the standard library. The main function adds a handler for the / route and sets up a listener on port 3000.

To containerize this, I just created a Dockerfile that looks like this:

FROM golang:1.19-alpine

WORKDIR /app

COPY go.mod ./
COPY go.sum ./

RUN go mod download

COPY *.go ./

RUN go build -o /hello-docker

EXPOSE 3000

CMD [ "/hello-docker" ]

This Dockerfile tells docker how to build my program, how to run it, and opens port 3000. Now I can build my docker image and ship it to whatever container platform I'd like.

AWS App Runner

The first container service that came to mind was AWS App Runner. AWS App Runner was launched in 2021, and offers developers an incredibly easy way to deploy web applications. It handles all the load balancing, auto-scaling, logging and monitoring for you. No servers to manage, no provisioning or configuring software packages. It just works.

It turns out, there are two ways to deploy a Go app on AWS App Runner--from a container or from your source code.

Creating an app from source code just requires you to connect AWS App Runner to your GitHub repo, configure a few settings and your'e done. You don't even need the Dockerfile!

Here are some notes on deploying my hello-docker web application on AWS App Runner.

Deploying from source code

1. The console will help you connect to GitHub, link your repo, and select your branch
2. Your repo doesn't need a Dockerfile
3. You can choose to use an apprunner.yml config file, or set the basic config within the console for build and start commands.
4. My build command looked like go build -o /hello-docker
5. My start command looked like /hello-docker
6. You can set up automatic builds on every update to your GitHub branch or update manually

Deploying from a container

1. First you need to build the container locally and push it to Amazon Elastic Container Registry (ECR)
2. You can choose from ECR private or ECR public repositories when setting up your service
3. Your source code won't require an apprunner.yml config file
4. You will need a Dockerfile similar to the one I pasted above to build your container image
5. One benefit is that your container on ECR can be re-used on various other container infrastructure like ECS, EKS, Beanstalk, and more. This seems very appealing since you can easily switch services in the future.
6. You can choose to do automatic deployments whenever you push a new image to ECR or update manually

I went through the paces of deploying both scenarios and they both worked equally well. I'm not entirely sure which is better, however I am leaning toward the docker based version since it seems more flexible and less concerned with the specifics of AWS App Runner itself (no need for additional config files, etc.)

Here's some additional nice things I noticed when poking at AWS App Runner.

• You can pause and resume an AWS App Runner service to save money while in development
• You can set up a VPC Endpoint to connect your AWS App Runner service to resources inside a VPC like an Amazon RDS database or an Amazon EC2 Instance.
• You can set up private endpoints and use AWS App Runner to host an internal API
• AWS App Runner handles auto-scaling, load balancing and custom domains
• You get built in observability with X-Ray as well as logging and metrics with Amazon CloudWatch

Overall I think AWS App Runner is a great way to host Go programs. I'm eager to continue working with it and see what else it can do. But, my favorite thing about AWS App Runner so far is the simplicity. The ability to point at a GitHub repo and launch a web app is super nice and a great way to rapidly prototype ideas on the Go.

The past couple weeks have been pretty productive in terms of my mission to learn Go. I started reading this excellent book called "The Go Programming Language" by Alan Donovan and Brian Kernighan. It's been helpful because it does a good job at explaining why things are the way they are in Go, while working your way through each core principal. I'm about 15% through the book already.

I also spent a good deal of time learning what I could about packages in Go. This seems to be a pretty important core concept, and something I've struggled with in other languages like Python and Node. I think Go has taken a really smart approach to package and dependency management by simplifying things, removing the need for a complex package manager, and creating a global namespace by just piggybacking off the World Wide Web's global namespace.

I also started building a package of my own to collect together some basic image processing functions. It's really just an exercise to learn more about Go and about building and documenting packages, but also has been a fun way to remind myself of some of the interesting concepts I learned about many years ago while studying imaging in college.

Here are my notes.

I learned all about Go Packages

Packages in Go are a core concept to understand. Here are some key takeaways:

• I'm not entirely sure what the difference is between a "package" and a "module" in Go, or if there even is a difference. Packages appear to be collections of Go files that can be imported into another Go program. Modules appear to be referenced in the form of go mod which is a command line tool that does the actual importing and documenting of versions.
• There is a special package called main that every Go program implements once and it's where your program begins. A Go Package doesn't need to have a main package.
• Packages can span multiple files and folders and your package namespace can use these folders to divide things up into logical groups. For example, you can have a package called "imaging" with a sub-folder called "generators" and you can import "generators" separately and parallel to anything else found within the "imaging" package.
• Your Go program can have many packages within the code-base. They get imported in the same way as a third party package from GitHub or elsewhere. I'm not entirely sure how Go works out which one to import, but it seems to prioritize local packages first.
• The namespace is global, which is nice because someone can publish a package at https://github.com/username/imaging and I can publish a package at https://github.com/go-micah/imaging and we can import both, giving one or both an alias so they don't conflict in the program we are writing.
• There is a website called pkg.go.dev where you can search for and browse packages and documentation. As a developer you don't need to upload your packages, you just let the site know you have one and it pulls in all the details from wherever you host your code. This is much nicer than PyPi or NPM in my opinion because there is always just a single source of truth for your code.

I learned a little about Go Documentation

Documentation in Go is pretty simple as well. In a nutshell, just add comments to your code.

• There is an old thing called godoc and there is a new thing called pkgsite which both allow you to view your docs in a web browser. The newer version presents a website that looks exactly like pkg.go.dev so you can preview how your documentation will appear once it's been crawled.
• The official docs on writing docs leaves me a little wanting. It's basically this blog post, which outlines most of what you need to know. At the top there is a link to this page, which has all the details of how to do things the right way. I also found this blog post useful in terms of getting pkgsite working.
• You can add an additional file to the top level of a package called doc.go where you can add high level documentation and examples.

I made a package of my own and a "Distance Image" function

As I mentioned earlier, I decided to learn by doing and created a package called imaging. This package currently has just one public function, but I plan to keep adding to it.

The function is called "Dist" and allows anyone to generate something called a "Distance Image" where the value of each pixel is relative to the distance to the center of the image. This is a useful thing to have anytime you need a quick test image.

It winds up looking something like this!

To do this, I made two functions in my imaging package. This first is a public function called Dist which takes the desired height and width of the image. (Capitalizing the first letter of a function makes it public.) The second is a private function called calculateDistance which uses the quadratic equation to calculate distance from any pixel to the center of the image. (There is some fun with rounding and converting ints to floats, which I will dig into in another post.)

Within the Dist function I wrote up a nested for loop, which will traverse the image, pixel by pixel. This is an important pattern to know about when dealing with images, and maybe in a future version, I will move it out to a draw function as I am sure I'll need to use it more than once.

You can already import this package into your own Go program like this:

import "https://github.com/go-micah/imaging"

And, you can already read the docs here.

That's all for now. Yay!

I've been getting going with Go for about a week now and I've already learned so much! I realized last weekend that I had two primary interests I want to focus on throughout my journey. The first is that I really want to learn the language itself, and get to a point where I can confidently type code and work through my ideas a reasonable pace. The second is that I am really interested in how developers can use Go on AWS.

So here's what I've been working on.

I spent more time going through the Tour of Go on the Go website. There are some things about Go that feel a little awkward at first, so I'm trying my best to rewire my brain a little.

For example, when declaring a variable in Go, you put the name of the variable first, and then its type.

var familyName string = "Walter"

Also, when declaring a function, you put the return type at the end, like this:

func getName(familyName string) string {
	return "Walter"
}

I also learned that if you capitalize the first letter of anything (variable names or function names, etc.) Go makes that object available (exported) to other packages and programs.

var FamilyName string
var familyName string

The other big thing I see in Go is that there's all kinds of shorthand expressions. This seems handy, but I'm sure it's gonna take some time to learn all of them before I can really read someone else's Go program.

For example, instead of this:

var familyName string = "Walter"

You could just type this:

familyName := "Walter"

Go will decide what the correct data type is on its own.

Playgrounds

It's pretty easy to create a folder and start hacking in Go on your laptop, but I really like having a browser based playground to try things out quickly. There is a nice, official, Playground on the Go website, where you can run code easily enough, but I also found this "Better Go Playground" which has some additional features that I find pretty handy--the main one being the ability to save and share snippets.

For example, I decided to try my hand at solving "FizzBuzz" in Go and saved the snippet here.

The "Go Better Playground" is a great tool for learning as it makes it super easy to try things out without the overhead of thinking about your local developer setup, or creating a repository. I can even see it being useful if I'm working on a larger project and just need a space to test some code, without having to compile the entire project.

As for FizzBuzz ...

FizzBuzz is one of the most common white-boarding exercises that technical interviewers use to weed out candidates in interviews. I first came across FizzBuzz when interviewing for a job about 10 years ago. When the interviewer brought it up, I had zero idea what she was talking about. I proceeded to work through the challenge, using a mix bag of languages and syntax, but ultimately solved the puzzle.

It's a fun challenge, but I have opinions about white boarding during interviews. More on that in another post I guess! And, in case you’re wondering, they offered me the job, but I ended up turning it down for other reasons.

FizzBuzz in Go was pretty easy to work through. It helped reinforce how to create a simple for loop and how to write a basic function. I had to think about converting data types from one to another, and I also learned about the strconv library, which came in handy when I needed to convert integers to strings. Yay, FizzBuzz!

Go on AWS

I work at AWS, so it makes sense I'd want to learn about running Go on AWS. To get started, I figured I'd try and build a simple "Hello Lambda" function in Go. I wound up making two.

Hello, Lambda

The first function I made was as bare bones as I could do. I mainly wanted to go through the process of creating a AWS Lambda function in Go, and deploying it to Lambda via the AWS Console. It was pretty easy.

1. A Lambda function in Go needs to import the AWS Lambda Go package.
2. The main function in your package main needs to start a handler function. This can be called whatever you want (I called my handler hello) and it's what Lambda will run when you invoke your function.
3. Once your function is ready, it needs to be compiled to run on Linux using the following command: GOOS=linux GOARCH=amd64 go build -o <your-executible> <your-go-source-file.go>
4. After you've compiled your function, it needs to be zipped.
5. Then you just create a new Lambda function in the console, selecting Go as the runtime, and upload your Zip file.
6. Finally, you will need to change the setting for the handler to the name of the executable file (not the handler function name)
7. I've got a few additional notes and code here.

Hello, Serverless Application Model

Dealing with Go in the AWS Console works, but there are some limitations. You can't live-edit a Go function in the AWS Lambda console. This means that you need to write, edit, and test your Go code somewhere else before deploying it to AWS. This is ok at first, but once you get into the weeds of developing something complex, the development lifecycle might get pretty tiresome. To alleviate this concern, I started to explore the various infrastructure as code frameworks available (there's a bunch now!) for AWS Lambda and Go.

After some quick research, I decided to explore the AWS Serverless Application Model (SAM). I've used SAM in the past with other languages. It was super easy.

SAM provides a very nice toolset for Go, and even has a built in template for setting up a basic API with a Lambda function. You just install the SAM CLI and run sam init and follow the prompts, selecting Go as your runtime. The CLI will then build you a project with a SAM template, a basic Hello, Lambda function, and a Makefile to automate the build process. You can then use the SAM CLI to deploy your Lambda function and API Gateway to your AWS account.

Here is what the SAM CLI built for me. I haven't really made any changes so far. I just ran through the deploy process and got my simple API to work. This is fun! Now I have a way to build out a Go based API on AWS Lambda, and I can use SAM to test and debug my code locally.

That's all for now. Now Go away!

I'm gonna learn Go! Not the 2500 year old Chinese board game, the 13 year old programming language developed at Google.

I have a little experience with Go, but not much. Years ago I wanted to learn Go, but my efforts stalled. Eventually, I learned enough to build a few AWS Lambda functions, and later I even contributed code to an open source project I care about. But, to be honest, it was all mostly copy and paste, and I never felt like I really "learned" Go.

So now, I'd like to try again, and learn it properly, from scratch.

Why Go ?

I've been interested in Go for a long time. It appeals to me for a number of reasons.

1. It's pretty easy to read. I like the structure of the language, and the consistency and style that programmers are encouraged to utilize. It's clean, and pretty readable, once you learn all the various shorthand.
2. It's fast! Go is a compiled language, which means you compile your code into a binary file for the underlying operating system ahead of running the code. This offers lots of efficiencies and performance benefits. I like fast.
3. It's statically typed? - OK, .. I admit, this seems like one of those things I may not directly benefit from at first. I mean, I get what it means to be a statically typed language, and I understand how that could be beneficial down the road. For now though, I am guessing it will just feel like more work and could be conceptually more difficult to understand. But, this is one of those "Why Go?" reasons you will read about.
4. Dependency management seems good. Go has a really pleasant way of dealing with dependencies. I don't yet fully understand how it works, but there's no need for pip of npm or yarn and all that noise. It's just built in and uses git repos. Seems nice!
5. It's a supported runtime on AWS Lambda. I'm keen to use Go on Lambda, so that's also nice.
6. It's one of the supported languages you can use to write CDK code in. I'm a huge fan of the CDK. You can of course mix and match your CDK language with your Lambda language, but it's comforting to know you could do it all in Go!
7. I'm a curious person who wants to learn something new.

That last one is really my main reason for continuing to explore Go. I'm pretty confident with Python, which is the language I run into most of the time at my job. I can find my way around a JavaScript or even a TypeScript program pretty easily. Don't get me started on PHP, and I'd probably have to break out the college text books to talk about C++. I'm genuinely just curious to try something new, something outside my comfort zone, and I think the statically typed aspect of Go might help reinforce some concepts I haven't had much exposure to.

Where to start?

Even though I've got some experience with Go, I'm gonna set out on this journey as if I'd just learned of Go today. To get myself started, I have a few ideas.

1. The Go website has loads of tutorials and getting started resources. I'm gonna go through all that to begin learning the core concepts of the language. In other words, I'm gonna read about Go.
2. I'm also gonna learn by doing. I'm gonna spend some time each day hacking on some simple projects. These will likely be very AWS focused, since that's my main area of interest.
3. I'm gonna share my learning with you all via this website, and I'll publish all my code on GitHub. A while back I created a GitHub Organization just for my Go code. I've resurrected it, and I'll use it as a place to share my notes, my code, and anything else that comes my way. It's called "go-micah", naturally!
4. I'm also planning to make more contributions to a few open source projects I love.

What I've learned so far

Here are a handful of notes on what I've learned so far.

1. The online tutorials a super good. The "Tour of Go" is interactive and thorough, and a great way to learn basic concepts. I already learned that Go only has one looping construct in the form of a for loop. That makes total sense!
2. There is something called fmt. I'm just starting to explore the standard library. I keep saying fmt like "fumpt." That can't be right.
3. There is a Playground to try things quickly.
4. You can explore and publish your own packages via pkg.go.dev. One thing I noticed is you don't need to upload your code here. You just make it aware of your code on GitHub or other places and it pulls it in.
5. Getting set up to code isn't too hard anymore. I recall Go being a little difficult to install and configure. That no longer seems to be the case, and in fact, if you use GitHub Codespaces it's already installed and ready to go.
6. There is something called go mod and although I know it's about managing dependancies, I don't really understand how it works just yet. I mean, it works, but how?!
7. Today I wrote up a simple Hello World application in Go and deployed it to Lambda. I'll write up my notes on this in my next post. The short version is...it worked!

I have to say, I'm excited to learn something new, purely for my own enjoyment. I hope you'll follow my progress, and if you are also learning Go, please feel free to reach out!