I've not used Go before, but I'm not convinced Go over bash is a benefit in this scenario. It's introducing another dependency and more complexity into the solution, making it less useful for people who don't work with Go. Perhaps it's not aimed at those of us, that's fine but making something less portable to make it easier to build seems like a frustrating trade-off from a user perspective.
Obviously this is an open source side project, so it won't cater to everyone, I'm just skeptical of it being the benefit that it's claimed to be.
You only need to install Go if you're wanting to manually build the project (which is a good idea for security reasons). You otherwise just add the compiled binary to your path and you're good to go.
The tl;dr is that it will eventually have features that would be nontrivial to implement with bash, and Go is easier on the development-side than C (coming from a frontend dev experience).
You would also need the tool chain if you're not on the same platform as built it originally, unless I just skimmed over it outputting multiple binaries and selecting them by local system type. Otherwise I clone a project on my Mac and it tries to run the binaries at the last developer built on her Raspberry Pi.
Oh, I misunderstood; I thought you were shipping binaries in the git rep to be run as hooks, not that git-hooks itself was written in Go. If it's the git-hooks itself then yeah portability should be good. I do notice that you're only releasing binaries for Darwin and Linux; no love for the BSDs? Not that it's a big deal, since most Go stuff is trivial to build on any supported platform.
Obviously this is an open source side project, so it won't cater to everyone, I'm just skeptical of it being the benefit that it's claimed to be.