goreleaser VS delve

> This is a much faster way than setting up Github Actions to build an executable for every possible platform on every release

It's not even that hard. Just use GoReleaser.

https://goreleaser.com/

I also got my eyes on GoReleaser, which I will use in my (Go) projects.

With "xq", I went even further and automated the release process using GoReleaser. To publish a new release, the only thing I need is to create and push the Git tag. The corresponding GitHub Action will trigger a release process, and GoReleaser prepares the binaries and changelog based on declared conventions. The result has a high level of predictability, and no manual work is required.

Things I can't live without in a new Go project in no particular order:

- https://github.com/golangci/golangci-lint - meta-linter

- https://goreleaser.com - automate release workflows

- https://magefile.org - build tool that can version your tools

- https://github.com/ory/dockertest/v3 - run containers for e2e testing

- https://github.com/ecordell/optgen - generate functional options

- https://golang.org/x/tools/cmd/stringer - generate String()

- https://mvdan.cc/gofumpt - stricter gofmt

- https://github.com/stretchr/testify - test assertion library

- https://github.com/rs/zerolog - logging

- https://github.com/spf13/cobra - CLI framework

FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb

We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/tree/main/tools/analyzers

Goreleaser is nice. https://goreleaser.com/

I use goreleaser for packaging my binaries. I'm not currently doing RPM, but it does a lot of services and if you don't hunker down on a single solution, it might help with keeping your releases up to date/in sync.

There's some packaging issues, for example, we've always wanted to publish deb/rpm packages, but never got around to adding it to either promu or completely switching our build tooling over to GoReleaser.

At a recent job, we had slightly different containers for local dev; our backend containers (for a Go app) had Air [1] installed for live reloading, plus Delve [2] running inside the container for VS Code's debugger to connect to. We also had a frontend container for local dev, which didn't get deployed as a container, just as static files.

[1] https://github.com/cosmtrek/air

[2] https://github.com/go-delve/delve/

https://github.com/go-delve/delve/releases/tag/v1.21.2 Thanks Derek and the rest of the team for helping us to debug in a normal way!

My employer has a commercial solution for this but Delve does supports `rr` traces natively for this purpose, which gives a complete open-source solution (https://github.com/go-delve/delve/blob/master/Documentation/usage/dlv_replay.md).

delve and related IDE integrations

For time travel debugging in Go:

The Delve debugger for Go supports debugging rr traces: https://github.com/go-delve/delve/blob/master/Documentation/...

Undo (who I work for) maintain a fork that debugs our LiveRecorder recordings: https://docs.undo.io/GoDelve.html

Either rr (https://rr-project.org/) or our UDB debugger (https://undo.io/solutions/products/udb/) can do some time travel debugging of Go programs via GDB's built-in support for Go. I believe its weakness is in support for goroutines, since they don't map well onto its idea of how programs run.

So in my case I use https://github.com/leoluz/nvim-dap-go (which itself calls out to the CLI tool https://github.com/go-delve/delve).

Clone https://github.com/go-delve/delve.git