I agree — tools should be shared artifacts that the team downloads and can guara... | Hacker News

Hacker Newsnew | past | comments | ask | show | jobs | submit

		peterldowns 9 months ago \| parent \| context \| favorite \| on: Go 1.24's go tool is one of the best additions to ... I agree — tools should be shared artifacts that the team downloads and can guarantee are the same for everyone. I usually setup a flake.nix for everyone but flox, earthly, devenv, jetify, are all great alternatives. Ideally your tools are declaratively configured and shared between your team and your CI/CD environment, too. The `go tool` stuff has always seemed like a junior engineering hack — literally the wrong tool for the job, yeah sure it gets it working, but other than that it's gross.

arccy 9 months ago [–]

well now it leans in to go's reproducible tooling so it's declaratively configured and shared between your team and your CI/CD environment too.

peterldowns 9 months ago | [–]

There are many tools that arent written in golang, and therefore not manageable via this approach. I don’t really understand why I would use this.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact