Aux is growing and we need to put together a set of contributors responsible for maintaining go packages. If you want to help, please reply in this topic with the following information:
Reason: (why do you want to be a go maintainer for Aux?)
Experience: (examples of past experience maintaining packages)
Reason: I would love to try helping maintain the Go stuff. 95% of my daily work and personal dev is in Go. I regularly use the latest versions, and would like to help with that.
Experience: Specifically maintaining Nixpkgs, not much. But I am the maintainer of a few Dart libraries and do releasing and managing of those. I also have some Go tools and libs that have releases a s such.
Reason: I write a bunch of Go on NixOS for my research and side projects. See e.g. dshuf
Experience: I am familiar with the language, its tooling, and a bit the Nix tooling.
Reason: Go is my most used language aside of JS and I often use or need different versions. Previously done that through mise, now Nix. Beyond that a lot of tools I personally use and depend on are in Go.
Experience: Not much in regards to Nix packages directly, though I’m working on it and am familiar with some of the Go specific aspects like gomod2nix. I’m also familiar with the language and its tooling as well as keeping up with new releases.
Reason: I used Nix extensively for managing my Go software and deploying to my homelab.
Experience: Writing Nix blog posts, used to be the Nix maintainer for the ghz package, extensive experience in the Go ecosystem (GitHub profile).
Reason: I’ve used Go since before 1.0, a distro where Go doesn’t work excellently is unusable to me I also have some longstanding papercuts that I’d love to try and fix, most notably the busywork of updating vendor hashes (at my day job we built nardump and some CI gunk to help automate this).
Experience: used Go for >10y, contributed small things to upstream Go (e.g. x/net/bpf package), used to maintain some Go packages in Nix (tailscale, perkeep, gotools, zrepl, pixiecore), have done some cursed things around building Go code (e.g. the gocross wrapper and its autoflags code to wrangle complex build configs) so I know some dark corners of the build machinery.