zedshaw.games

This is a learning projects for me to learn Go. It's a simple website that serves past stream information, a place to post links during stream, and the games I've made while live streaming.

Getting godoc To Work

There's a built-in command go doc but there's also a more advanced tool by Google called godoc. I know, amazing naming. Anyway, to get it you do this:

go get --tool go.googlesource.com/tools/godoc@latest

You can then run it and start indexing everything you've installed and also yourprojects packages, plus get a nice web browser based search page to view the docs:

go tool godoc -http=localhost:6060 -index

NOTE: Google doesn't know how the internet works so you have to use localhost:PORT and not 127.0.0.1:PORT when you run this.

After that it'll take some time to index everything but you can already start browsing the APIs you need, and your project's stuff is in the Third Party section.

Dealing With Module Bullshit

The way to think about Go's modules is that they don't have modules, they have "projects." Every directory's .go files export all of their functions without any namespacing based on the file's name. So if you put FooBar into tools.go and Dipshit in fuckyou.go then your namespace for all files has raw dogged FooBar and Dipshit without any reference to tools or fuckyou.

That's because your root directory is a whole project, not a module. To then create a namespace you have to make a directory, place the files in that directory, and add package mymod at the top of those files. You then have to import this as if it's an entire fucking project everywhere you want to use it:

import 'mywholewebsite.com/rootproject/subproject'

In this case you have a directory subproject and in there are a bunch of .go files with package subproject at the top to indicate they are in that subproject. Thinking about Go's modules as separate projects helps to sort out this import statement.

1. mkdir tools
2. Create files in tools/ with package tools
3. import "zedshaw.games/webapp/tools" to get the subdirectory

Why Did Go Do This?

That's because it comes from Google, and Google is famous for two things:

1. Using a monorepo.
2. Assuming everyone else uses a monorepo.

Don't believe me? Go look at the official first document covering modules and you'll see they create two totally separate projects at the root which then link to each other. That's not how anyone else thinks when they make a single project to work on, but if you're suffering in monorepo hell you'll do it this way.

I'll also posit that Google has some weird incentive that measures numbers of projects in the monorepo as some kind of metric for employee productivity, so everyone working there is motivated to get as many little projects into the monorepo as possible, thus a great way to get them to adopt Go is to make Go support pulling tons of random projects from the root of a monorepo.

So that's why you have to put your whole entire domain name into the import, and why you have all the functions just raw dogged into your face when you make multiple files, and why subdirectories are treated like whole little projects.