We use go:generate to generate services and types from protobufs.

    //go:generate protoc --go_out=src/generated/ protos/service.proto

Our CI pipeline is a dockerfile that looks vaguely like this:

    FROM golang:1.21 as build
    go generate
    go build
    go test

    FROM scratch
    COPY --from=build ...

The CI steps are: docker build <XXXX> && docker push <XXXX>

We have a goland project template that has options for generate, build, test that matches what we do in CI rather than having that _one_ edge case that is the difference between `make build` and `go build`. That difference has caused more than one outage in my career.

One example that comes to mind is building a single-binary full-stack application.

You can use whatever frontend framework you want, and just embed the html/css/js/asset files inside the binary with go:embed. In case of dynamic set of files, you can also write a Go utility to generate the embeddings with go:generate.

In addition to the ease of distribution (no more assets/ directory - just a single binary executable!), it also increases speed of the application, as it no longer has to perform file system reads in order to serve a webpage.

I've used go:generate to generate a set of structs based on an XSLT document. That said, since XML is fairly uncommon these days in popularity, the generator was a bit buggy still.

And I've used go:embed to include .sql files for database migrations and querying. I should really spend some time on this POC I made (sqlite, goose for migrations, and an implementation of temporal tables) and publish it as a demo.

Not OP, used embedded to add ebpf code compiled for a project, helps to only ship the binary. Same thing for shipping swagger static html stuff to host an OpenAPI server.