blog

GoLang for Python Devs

Mon, 23 Mar 2026 00:00:00 +0000

This post is a text version of the code samples and resources from Golang for Python Devs by Dana Garifullina from Kiwi PyCon 2016.

Some resources no longer work, so I’ve updated to the most accurate thing I can find.

Some Python samples were Python 2, updated to Python 3.

Most code OCR’d, may contain translation issues

Hello World

Python

print("Hello World!")

Golang

package main

import "fmt"

func main() {
	fmt.Println("Hello, KiwiPycon!")
}

Lists

Python

# initialise a list
arr = []
# initialise sized List
arr = [0]*12
# add one element
arr.append(20)
arr[0] = 21
# Length of list
len(arr) # 13
# List extending
arr.extend([4, 5, 6])
# get element by index
arr[2] # 0

Golang

func main() {
	// initialise a list
	var arr [3]int // ［9, e, 9］
	// change element via index
	arr[0] = 125
	// SLICES - when you don't know size
	// of List
	colours := []string{"red", "blue"}
	// append == recreation
	colours = append(colours, "purple")
	// Length, capacity
	fmt.Println(len(colours))
	fmt.Println(cap(colours))
}

Dictionaries (maps)

Python

#initialisation of dictionary
py_map = {}
# add element
py_map["first_key"] = 25
# delete element
py_map.pop("first_key")
# re-fill
py_map = {"first_key": 26}
# print element
if "first_key" in py_map:
	print(py_map["first_key"])
# or just
print(py_map.get("first_key"))

Golang

func main() {
	// initialisation
	go_map := make(map[string]int)
	go_map["first_key"] = 25
	fmt.Println(go_map["first_key"])

	// remove by key
	delete(go_map, "first_key")

	// print element
	if element, ok := go_map["random_key"]; ok {
		fmt.Println(element) // won't be printed
	}
	if element, ok := go_map["first_key"]; ok {
		fmt.Println(element) // 25
	}
}

While Loop

Python

# while Loop
i = 1
while i <= 10:
	print(i)
	i += 1

Golang

func main() {
	// Loop from 0 until 10 is reached.
	for i := 1; i <= 10; i++ {
		// Display integer.
		fmt.Println(i)
	}
}

Infinite Loop

Python

# no condition
id = 10
while True:
	if id > 20:
		break
	print(id)
	id +=5

Golang

func main() {
	id := 10
	// This Loop continues infinitely until broken.
	for {
		// Break if id is past a certain number.
		if id > 20 {
			break
		}
		fmt.Println(id)
		id += 5
	}
}

Range Loop

Python

#for Loop
for i in range (0, 25):
	print(i)
# other way
names = ["Peter", "Anders", "Bengt"]
for i, name in enumerate (names):
	print("%d. %s" % (i + 1, name))

Golang

func main() {
	names := []string{
		"Peter",
		"Anders",
		"Bengt",
	}
	/* This will print
	1. Peter
	2. Anders
	3. Bengt
	*/
	for i, name := range names {
		fmt.Printf("%d. %s\n", i+1, name)
	}
}

If Statements

Python

# if-elif-else switches
value = 1.0
if value == 1.0:
	print("This is 1.0 but I will print...")
	value = value + 0.5
if value == 1.5:
	print("One point five")
elif value == 2.5:
	print("Two point five")
else:
	print("Anything else")

Golang

func main() {
	value := 1.0
	// Switch on a floating-point value.
	switch value {
	case 1.0:
		fmt.Println("This is 1.0, but i will print...")
		fallthrough
	case 1.5:
		fmt.Println("One point five")
	case 2.5:
		fmt.Println("Two point five")
	default:
		fmt.Println("Anything else")
	}
}

Exceptions

Python

try:
# An error occurs.
	x = 1 / 0
except:
	# Except clause:
	print("Error encountered")
finally:
	# Finally clause:
	print("Finally clause reached")

# another example
while True:
	# Read int from console.
	denominator = int(input())
	# Use int as denominator.
	try:
		i = 1 / denominator
	except:
		print("Error")
	else:
		print("OK")

Error handling

Golang

func explode() {
	// Cause a panic.
	panic("WRONG")
}

func main() {
	// Handle errors in defer func with recover.
	defer func() {
		if err := recover(); err != nil {
			// Handle our error.
			fmt.Println("FIX")
			fmt.Println(" ERR", err)
		}
	}()
	// This causes an error.
	explode()
}

Open (name string) (file *File, err error)
f, err := os.Open("filename.ext")
if err != nil {
	log. Fatal(err)
}
// do something with the open *File f

OOP in Go

package main

import "fmt"

type Attendee struct {
	Topic  string
	Person Person
}
type Person struct {
	Name    string
	City    string
	Company string
}

func (a Attendee) SayHi() {
	fmt.Printf("Hi, my name is %s and today I will talk about %s! \n", a.Person.Name, a.Topic)
}

func (a Attendee) About() {
	fmt.Printf("I'm from %s and currently working in %s by the way. \n", a.Person.City, a.Person.Company)
}

func main() {
	guy := Attendee{
		Topic: "Meetings with cookies: never have less then 10",
		Person: Person{
			Name:    "John Doe",
			City:    "Doeville",
			Company: "WeCodes Inc",
		},
	}
	guy.SayHi()
	guy.About()
}

Empty Interfaces

package main
import (
	"fmt"
	"strconv" // for conversions to and from string
)

type Person struct {
	name  string
	age   int
	phone string
}

// Returns a nice string representing a Person
// With this method, Person implements fmt.Stringer

func (p Person) String() string {
	return "<<" + p.name + " - " + strconv.Itoa(p.age) + " years - @" + p.phone + ">>"
}

func main() {
	John := Person{"John", 29, "022-4XX-66X"}
	fmt.Println("This Person is: ", John)
}

Concurrency

import (
	"fmt"
	"time"
)

func main() {
	go sayHello()
	fmt.Println("Going to sleep....ZZzzzzzZZ")
	//make main last a little bit more
	time.Sleep(6 * time.Second)
}
func sayHello() {
	fmt.Println("Waking up....")
	time.Sleep(3 * time.Second)
	fmt.Println("Hello KiwiPycon!")
}

// Going to sleep...ZZzzzzzZZ
// Waking up....
// Hello KiwiPycon!

Channels and Defers

(complicated, see talk)

Resources

Books:

http://www.golang-book.com/books/intro
- no longer works. Try https://github.com/ashleymcnamara/an-introduction-to-programming-in-go
Introducing Go by Caleb Doxsey http://shop.oreilly.com/product/0636920046516.do

Official docs:

A tour of Go: https://tour.golang.org/welcome/1
Effective Go: https://golang.org/doc/effective_go.html
Blog: https://blog.golang.org/

Talks:

The Evolution of Go https://youtu.be/0ReKdcpNyQg
Concurrency Is Not Parallelism https://youtu.be/cN_DpYBzKso
- Probably https://go.dev/blog/waza-talk
Simplicity is complicated: https://youtu.be/rFejpH_tAHM

Articles:

Traps, Gotchas, etc for New Golang Devs: http://goo.gl/ijZVrw
- http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/
Five things that make Go fast: http://goo.gl/WYPJ8K
- Probably https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast

Announcement - New paper

Tue, 01 Apr 2025 00:00:00 +0000

Happy to announce that after learning my way around research papers with ACROSS, I’ve published a new paper.

Sadly I don’t have a journal to contribute to (I’m still learning that part without guidance), but I’ve pushed the PDF and raw data up on GitHub.

This one was a long time in the making (original research was from 2019), but hopefully it’s now in a form that can be shared with the scientific community to better understand the domain of fluid conveyance.

Generative epiphany

Thu, 14 Nov 2024 00:00:00 +0000

I’ve recently been learning more about Generative AI and LLMs as part of my day job, and was having problems understanding some of the concepts. Evals, fine tuning, etc; it was all confusing to me.

Until I had an epiphany, and realised that I already have a mental model for this sort thing already: containers.

Dockerfiles that build containers are just instructions to build a tarball. That container image without the instructions is a black box. That black box could be an LLM Model.

Prompt engineering is changing the entrypoint of a LLM model.

Fine Tuning is adding more to layers into the container, by adding to the Dockerfile, adding onto the existing base container.

Evaluation is comparing the outputs of two different containers with custom args, or different base images.

Retrieval Augmented Generation (RAG) is connecting to a database. That could be a SQLite flatfile to add into the container, or it could be a live SQL database, information that is not baked into the model/container.

Functions are just functions, connecting to APIs.

HuggingFace is just Docker Hub, or any other hosting platform for blobs of stuff that you can call down by name.

You can also skip the whole Dockerfile part and use named models from a hosting provider, sort of like using Cloud Functions or Buildpacks for named programming environments. E.g. gemini-1.5.-pro is just contents of the .python-version file.

You will never see the contents of the Dockerfile, unless you build it yourself (and you may not need to, depending on your use case, you don’t have to start FROM scratch).

Note: this blogpost is more for me than anyone else, but please let me know if this helped map the concepts in your mind!

A decade of public speaking

Mon, 04 Nov 2024 00:00:00 +0000

Previous articles: 2015, 2016, 2017, 2018, 2019

A decade ago today, I gave my first conference presentation.

Talk 95 - Where should I run my code? Dublin, Ireland, Nov 2019

~ much time passes ~

Talk 124 - Present like a pro, Wellington New Zealand, Aug 2024

Well. The last five years. What can be said that hasn’t been said many times already.

I ended up working for exactly one year as a Developer Advocate before the lockdowns started. My ““Googleversary”” was the first day I would work from home. I have since moved to perma-remote (and moved cities!)

Turns out when you peg your career on the ability to travel and speak, and travel stops…

During the height of lockdowns, I did more podcasts than anything else, but I did do a few remote events. The lack of feedback and energy from presenting online is definitely… something. Being in UTC+10 with online events spinning up left and right (and in mostly UTC-negative timezones) didn’t help with the inclusiveness. But the joy I felt giving my first in-person talk in two years in a small meetup room where the front row was full of humans I adore and hadn’t seen in a while… that is why I do this speaking thing. The ability to help people learn technical concepts, and learn from others, in both an event structure that works well with my brain (and having months to plan the words that will come out of my mouth during my presentation), it really works for me.

However, my career has pivoted again during the lockdowns. I ended up working more on that scalable advocacy thing I mentioned last time, helping to develop tutorials and written work that then resulted in moving from Developer Advocacy to Developer Programs Engineering (in not-company terms: moving from the talky talk to the codey code). Google has since consolidated both roles into a general “Developer Relations Engineer” role, so I have scope to do both talky and codey! (Obligatory “Look mum, I’m a Google Engineer!”)

I haven’t stopped speaking though! I’ve definitely hit that experience level where I can genuinely give the ‘speaking about speaking’ talk (which I was presenting internally before taking it on the road), and the feedback I’ve gotten about being inspiring to the next wave of speakers has been delightful.

Oh, and I’ve also presented talks at company events in Las Vegas, London, and Tokyo; given a few more keynotes, including one in two languages with live translation. I’ve spoken at more meetups, and I’ve also gotten to present in proper recording studios. But I’ve also guested on podcasts. You know, like a proper thought leader.

What will the next decade be like? It’s been a while since I’ve created a brand new talk, so that’s something I look forward to having the time and space to do again. Not to say that repeating talks isn’t work: the refinement and polish some of my encores have given makes them some of my proudest work. But the blank canvas is always appealing (and terrifying!).

Here’s to another decade of making the words on a stage. 🎤

Getting GitHub Review Requests per Team

Fri, 23 Feb 2024 00:00:00 +0000

In both my day job and my community work, I use GitHub. A lot. And I’m asked to review code on GitHub. A lot. At the time of writing I have over 100 review requests on the platform.

When I have things that require reviewing, I’m normally notified by email. But the email footer doesn’t tell me much about why I was requested.

I can also use the Review requests page to view all my requests. In this view you can filter by organisation, and sort by age and such, but this still doesn’t help me identify why I was requested.

There’s also the Notifications view, but I don’t use this very often, and I have Inbox 1000+ over there. This view does have at least a search option, but I don’t use it often.

What I would like is a view of what pull requests I’ve been requested on, and why. What is directly to me? (This is most important, as it’s a specific request.) Was it to a team where I’m a maintainer? (This might be important right now, or maybe there’s other folks on the team who can address). Was it to a team that is a large one with specific rotational duties? (It might not be important right now, but might be when I’m on rotation).

So I write a script using PyGitHub that goes through the following logic:

Return all pull requests from the “Review requested search”
For each of those:
- Pull the list of Review requests
- For each request:
  - Is it a user? Is it me? Log the PR as a “direct request”
  - Is it a team? Am I an active member? Log the PR as a request for that team.
For all the team groupings, group each PR by repo, and output the PR by Team, Repo, PR ID, title, and a link to the request.

There are more options that could be added here, like “Is it for a team I’m a maintainer of? Log this separately”, or “Is this for a team I’m on rotation for? Log this higher”.

My exact needs are specific, but I’ve created a general script that you can expand on. It will currently return a flat list of teams and pull request URLs, ordered by team name.

Running this script for my own requests, I will get all the direct requests at the top, then any team requests sorted alphabetically (because the underscore character sorts higher). With this output, I can get information to help prioritise my time.

Update: While reviewing this post, I found the ability to filter pull request reviews by ones directly for you, or ones for you or a team. Read about it on puff!

With thanks to Adam Ross for reviewing this post!

Auto-provisioning Artifact Registry though Cloud Run Source Deploys

Thu, 15 Feb 2024 00:00:00 +0000

One of the neat features when developing in Cloud Run was knowing you can use gcr.io/yourproject as a place to push your Docker containers. This is a Container Registry (the CR in GCR.io), and would be available as soon as you created your project, ready for your containers.

Container Registry’s implementation included the interesting detail that the container layers you pushed would end up in Cloud Storage (specifically the artifacts.yourproject.appspot.com/containers bucket.) (It’s one of those buckets that appears with yourproject_cloudbuild (which is for Cloud Build. It’s usefully named.)

However, as of May 2023, Container Registry is deprecated, being replaced with Artifact Registry. Once set up, a Docker registry in Artifact Registry works the same as it would as Container Registry (only now it doesn’t use Cloud Storage). You’ll get a REGION-docker.pkg.dev/yourproject/yourregistry link you can find/replace with your existing gcr.io URLs (or you can set up domain redirection and not even have to do this update).

A new thing that is required with Artifact Registry is that it doesn’t come as standard in your project. Artifact Registry supports more than just Docker containers, and you have to create your Docker registry before you can use it.

A trick I often use, and would suggest using, is getting your registry automatically provisioned using Cloud Run Source Deploys.

Within your application source code directory, if you run gcloud run deploy, you’ll be using --source . deployments. This method will build your container using a Dockerfile (if it exists), or use Cloud Buildpacks (for supported languages). Behind the scenes, the first time you run this command in your project, it will create an Artifact Registry called cloud-run-source-deploy in the same region as your service.

The run deploy method also is a nice helper around the combination gcloud builds submit; gcloud run deploy --image command, that may be familiar you.

Once your service has been deployed, you can find the image that was created by interrogating the service with gcloud run services describe, or getting the value specifically:

gcloud run services describe yourservice \
   --region yourregion \
   --format "value(spec.template.spec.containers[0].image)"

Developer processes change over time, but as platforms evolve, the experience should improve developer quality of life. With Source Deploys’ integrated functionality in other parts of the deployment pipeline, you can spend less time deploying and more time coding. ✨

With thanks to Jennifer Davis for reviewing this post!

Building GitHub Pages with GitHub Actions

Tue, 12 Dec 2023 00:00:00 +0000

A lot of writing on this blog stems from meta content about the blog. This is completely fine. It also helps me pinpoint that it’s been 9 years since I first moved my content into Jekyll.

I was using the integrated GitHub Pages functionality (a website that seems to have not changed much since I first migrated to it), but one of the issues I’ve written about it before is that I was locked to the version of jekyll, and didn’t have much control over the processes involved.

Recently I’ve been having issues where I’d have to deploy ‘noop’ changes just to force a re-build and new content to be published.

But as of today, I seem to have been succesfully able to use a new beta functionality, where my action can build the site, then I let actions/upload-pages-artifact and actions/deploy-pages take care of the rest.

I’m using a combination of the jekyll and jekyll-gh-pages starter workflows. (These are the suggestions that show up if you go to Actions > New Workflow on a repo). You can see the setup I’m using in .github/workflows/publish.yml (this may be further refined).

When changing from the existing method, I needed to go to Settings > Pages > Build and deployment, then change my Source from “Deploy from branch” to “GitHub Actions (beta)”, otherwise I’d get permissions errors on deployment. I also had to change the (inherited? defaulted? legacy’d?) branch protection on the github-pages environment, but I’m unsure if that was a configuration I made, or one that migrated with me.

In any case, I seem to have a blog that now deploys from a push to main to my website in just shy of 40 seconds, which is good enough for me!

Here’s to another nine years of futzing ✨

Using Cloud Buildpacks images as Cloud Build steps

Tue, 21 Nov 2023 00:00:00 +0000

In Cloud Build, you can create steps, with each step using a base image. Images can be common ones to interact with gcloud or docker, but you can also create your own.

When building custom images in Docker, you might have your ENTRYPOINT as the name of an executable, then you can send various runtime parameters to it. How the docker Cloud Builder image is defined in the Dockerfile

However, when you’re using Google Cloud buildpacks, you specify an optional Procfile with your application, when you need to configure an application entrypoint different to the default.

Problems arise if you’re trying to define a custom entrypoint, then additionally customise the runtime parameters. The Cloud Native Buildpacks Specification v3 doesn’t (at the time of writing) specify how a Procfile should be processed, so the implementation is up to the provider.

You can use pack inspect to see how an image’s processes have been parsed into a command and arguments. For instance a Procfile of web: python main.py used in a cloud buildpack may result in the following:

Processes:
  TYPE           SHELL        COMMAND           ARGS
  web (default)  bash         python3 main.py

Specifically, the entrypoint was parsed as a complex command, and not a single command with zero or more args.

The complexity of exec and shell form ENTRYPOINTs in Docker aside, there is a simpler way to solve the issue.

The way I found to reduce the complexity is to introduce an execution detail where you allow the python file to be executable, or package it, in that such a way that at the operating system level, it’s a single command to start the process.

Take the following example, where the image is build in build.cloudbuild.yaml and built in cloudbuild.yaml: GitHub Gist

The image is built specifically using the --workspace flag of not the default workspace. /workspace is used by both Buildpacks and Cloud Build, and in my investigations I found conflict here. The default volume /workspace is used by Cloud Build to pass information between steps, but also as a source of the files within your current working directly when running Cloud Build configurations. If your image also uses this as the default workspace, when using Cloud Build, the image contains none of your custom files.

Additionally of note, I’m using main.py here. Recent changes to Cloud buildpacks means that Python buildpacks now use gunicorn main:app as a default. This functionality is similar to how App Engine works.

Other languages that have single executables may not have these issues to begin with.

I’m also sure there’s cleaner patterns. but this one has worked for me.

Getting contextful `latest` images for IaC

Tue, 15 Aug 2023 00:00:00 +0000

If you’re using Infrastructure as Code for declaring your serverless applications, you may encounter issues if you’re relying on latest container tags.

latest is used in Docker when there is a lack of tag – if you’re not using other tags, it will typically be the most recent image to be built, as therefore “latest”.

However, if you’re using tools like Terraform, you may be declaring this image without a tag, or explictly as latest. If you rebuild your image, then apply your IaC changes, your service will not refresh, enough though there’s a new image.

In Terraform and other IaCs, they will confirm the configured value against your infrastructure. Even if the reference to the latest image has changed, it will still see something like gcr.io/myproject/myimage:latest as being the current value, and this no change is required.

A way to get around this is to not map the image name directly, but to map the image digest. The digest is a SHA256 hash of the docker image. If there are no changes in the source code between image builds, the digest will not change. If there are changes, the digest will be updated.

If you link the image digest to your service, then you can allow your service to be updated only if the image has been updated. The digest won’t change even if there’s a new image built with the same SHA, thus you only update when required.

Getting the digest can be complicated, but it is possible using a bit of extra logic.

In Terraform, you can use the docker provider to inspect your docker registry. You can then get the digest from that, and use that in your image URL. An implementation of this can be seen in the avocano application.

In Pulumi, instead of using the image_name, you can use the repo_digest, which will be the full image plus sha identifier. Changing this reference in the container-gcp-python will make the pulumi up method update the service if and only if the application code is updated.

Running Cloud Build with Pull Request context

Wed, 02 Aug 2023 00:00:00 +0000

When using Cloud Build pull request triggers, especially when the trigger is to run tests, you’ll traditionally be running your “run my unit tests please” command which will run every test across your entire repo.

But in cases where that takes a long time, it might be useful to only run tests for pull requests across the code that’s been changed.

You might be familiar with using a test suite that runs tests for the file you’re changing when you’re developing locally, so for sufficiently complex repos, it might be useful to replicate this in CI.

When Cloud Build starts, it will fetch a shallow clone of your repo. This is greatly advantagous for complex repos with long histories, but it means that you don’t have the detail of seeing what the current diff is. (For git clone --depth 1, the git diff is the entire repo has been added under the most recent commit).

There are ways around this, however. Cloud Build provides substitution variables for the base branch (which will return main, latest, or whatever you’ve configured as your default branch), and the head branch (the branch of the pull request). Using these two values, you can ask the cloned git repo to tell you the sum total of the changes from this pull request (the same view you’d get on the “Files changed” tab in GitHub).

The git commands to do this are:

git fetch --unshallow
- fetches all of the information
git diff origin/${_BASE_BRANCH} --name-only
- gives the names of the files that have been changed between the base branch and the (implied) current branch.

(Update 2023-10-17: A previous version of the blog psot used origin/${_BASE_BRANCH}..origin/${_HEAD_BRANCH}, which won’t work for forks. H/T to Roger for the fix!)

From there, you can do your own logic to work out which tests need to be run.

As an example, I have a repo full of folders, each of which have their own tests, and I’m using pytest, which without any other arguments will run every test_*.py file, even in nested directories.

However, I can parse the output from git to work out which folders have had changes, and tell pytest to only run test in the folders which have been changed. In my case, I want to run tests in the entire folder if anything within that top level folder has changed.

To do this in Cloud Build, I would setup something like the following:

steps:
  - id: retrieve delta
    name: gcr.io/cloud-builders/git
    entrypoint: bash
    args: 
      - -c
      - | 
        set -e
        git fetch --unshallow
        
        # get the changed files
        git diff origin/${_BASE_BRANCH} --name-only > _changed_files
        
        # parse out the folders that have changed
        cat _changed_files  | grep '/' | cut -d '/' -f1 | sort | uniq | tr '\n' ' ' > _changed_folders

        echo "Change files:" && cat _changed_files
        echo "Change folders:" && cat _changed_folders
        echo "EOF"
  
  - id: pytest
    name: python:slim
    script: |
      #!/bin/bash
      pip install -r requirements.txt -U pip
      pytest $(cat _changed_folders)

For example, the resulting pytest command for a pull request that changes and db/src/mydb.py would be pytest db, running on my database unit tests. The integration tests tests in app/ won’t run, which could save hours of CI time.

In this example, I’m passing data between build steps, and making use of the git cloud builder, a container with git already installed and ready to go. I’m opting to use legacy inline scripting as opposed to the script field, because I have to rely on a number of environment variables. I could explicitly declare these, but the code is shorter without it. (I don’t need any variables in the pytest step, so I’m using the script field here.)

You could extend this example by checking if there are any changes that should fire playwright tests, or indeed run all tests if the cloudbuild.yaml file itself is updated.

Using a setup like this will mean you are potentially (and intentionally) skipping tests in pull requests, so it should be combined with scheduled builds to run all the tests nightly or weekly, which can take as long as you want (as long as your tests don’t take as long as the time between tests! Having nightly tests that take more than 24 hours is a horror story for another time.)