[zer00eyz]

Im a big fan of //go:build exclude ... and having separate CLI scripts in a project where I can.

Candidly I think that it's much easier to do this in go (or rust), rather than say python/ruby/node as I can use complied binaries without needing a run time.

Edit: //go:build ignore is idiomatic

[vundercind]

Go’s excellent for writing development tools and “scripts” if you have to support development on heterogenous platforms.

No per-platform install instructions, no “ok but you have to run this in WSL2… you don’t have that? Oh god, ok, let’s find those instructions…”, no “oh fuck the flags for that are different on BSD and Linux, so this breaks on macOS”. “Wait the command’s python3 not python, on your system? And also it’s erroring even after you fix that? Shit you’re still on 3.8, we use features that weren’t included until 3.10…”

“Unzip this single binary and run it. Tell your OS to trust it if it hassles you. That’s it.”

C# with mono might be close to as good? Not sure. Rust’s probably OK but a bit of an investment when you’re just trying to dash off some quick tool or script. C++ and C can do it but you definitely don’t want to. Java’s obviously out (ok, now update your JRE… wait, your env vars are all fucked up, hold on…).

Go’s also highly likely to be something another developer with or without Go experience can read and tweak after the person who wrote it leaves, without much trouble.

[sethammons]

Why use build tags for this over ./cmd/$toolname/main.go?

[bbkane]

Do build-excluded files get tested with `go test`? (tbf, not sure it's practical to test most scripty tasks)

[zer00eyz]

Think of this as a way to have a file with package main, and a func main that does not interfere with your normal build process...

The best example of this, and a decent util is this: https://go.dev/src/crypto/tls/generate_cert.go

All of the real testing happens elsewhere this just provides utility.