[fiatjaf]

All I wanted was a way to safely and easily cleanup my $GOPATH. I don't have a lot disk space and $GOPATH takes up most of it.

This thing apparently doesn't solve my problem. `go mod tidy` simply removes a dependency from a module, but that dependency is still cached in a big arcane directory at $GOPATH/src/mod. Why?

I think we all should be using something like Nix for dependency management that solves all problems, but that is so hard to setup!

[jerf]

Not having a lot of disk space is a minority case for developers now. I wouldn't hold your breath for the Go authors to address it.

If you have a disk space problem, Nix would seem to be the opposite of the solution to that. One of the ways Nix does its magic is to chew through disk space a lot more freely than most distros do.

[fiatjaf]

Also, there are a lot of people who think disk space is an issue. See https://pnpm.js.org/ for example.

(Ironically, pnpm doesn't have an auto cleanup feature.)

[jerf]

npm was especially broken with disk space, above and beyond what Go has ever had, so their problem was much worse.

And my point is not that disk space is never an issue. That's why I said it was a minority issue, not "not an issue". My point is more than Go is not a language about addressing every fiddly minority's issues. It's definitely about the 20% that does 80% of the work. So waiting for a language lead by a philosophy like that to address a disk space issue is probably not a good plan.

To be a bit more constructive, I'd observe I've had great experiences with cross-compiling. On the chance you're disk-space limited because you're developing right on a target resource-constrained device, you may be able to move your development to a more powerful system, even of a different architecture, and cross-compile fairly easily. I often have a workflow where I just "go build blahblahblah && rsync blahblahblah target:blahblahblah && ssh target blahblahblah" and I just press up & enter on a shell when I want to push & test the code. As long as you've got half-decent bandwidth to the target device, it's fine. There may be a couple of other buttons you may want to push to speed that up, because IIRC when cross-compiling it'll end up building the entire app, and you'll want to pre-compile things for the new arch.

[fiatjaf]

But it has automatic and safe cleanup, right? So I can use only what I need at any point in time instead of having an opaque directory full of unused stuff I don't know if I can delete or not.

[weberc2]

> but that is so hard to setup!

And sadly, to use. Nix is a great idea but it could do a lot to help itself out if it ever wants to become more than niche:

1. Use a more approachable package definition language; Starlark (https://github.com/google/starlark-go) or Lua would probably be great choices.

2. Make it reasonable to figure out what the "type" of a package dependency is so we can figure out how to use it and/or find its source code

3. Document package definitions. We document source code in typed languages; Nix expression language is untyped and generally less readable--why not document it?

4. Nix tools have a `--help` flag that only ever errors with "cannot find manpage". This is just user-hostile.

5. Using almost-JSON for the derivation syntax, but then providing a "pretty printer" that keeps everything on one line but with a few more space characters.

6. Horrible build output--everything for every build step (megabytes of useless gcc warnings) gets dumped to the screen. Contrast that with Bazel and company which only print errors.

Plus a long tail of other things I'm forgetting.

[fiatjaf]

I didn't manage to use it enough to get to these issues.

I stopped at the point that I had to keep track of an enourmous build.nix file in all my project directories that did a lot of magic if I wanted to use Nix for Go or JS package management.

I also failed completely to search and install executable packages from npm and other minor things I tried.

I did that after going through the complete Nix tutorial and managing to understand pretty much everything and love it.