This Week I Learned: 2021 W17

Published May 2, 2021

Go modules are the standard now, and generics are on their way

Last time I wrote Go, these were both experiments. It looks like go mod stopped being controversial, and it’s expected for new projects to use it. The recent proposal for generics got accepted, so I guess I should actually spend time learning this version of them.

go doc is really useful!

This is my first time working in a Go codebase that I didn’t help start, so I’m learning how to uncover the names of things I don’t know about yet. The go doc subcommand has been there for a while, but this is the first time I’ve actually used it.

I’ve been using this as go doc ./package or go doc ./package.Struct to see the exported functions, types, and methods of packages as I encounter them. It’s much easier than opening the files themselves when I’m just exploring!

We’re still arguing about Go project layouts

I remember finding something like this back in fall 2017 when my team started laying out a Go project. But now we have the big names involved!

One of the double-edged swords of Go is that URLs and filesystem paths are directly involved in the import system. It’s nice because it makes it easy for tools to find the code, but it means that you really have to think about your directory structure. Last time, we ended up starting with a main.go for each binary we intended to build and extracting things as needed. We eventually grew /cmd for subcommands and /vendor for go dep (RIP) similar to what the self-declared “standard” layout suggests, but everything else diverged completely. We made directories/packages as we found good abstractions and argued about them a lot.

This isn’t a problem specific to Go, though. I’m still not entirely convinced I know where to put plain Ruby code related to a Rails app. Maybe Erlang had it right and we should just live in a flat global namespace….