# 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:

```shell
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:

```shell
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:

```go
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](https://go.dev/doc/tutorial/create-module) 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.