Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Go Modules

blog.golang.org

Post reply on HN
Print view View original

111–120 of 124 posts

Re: Using Go Modules

#111

Post by sudhirj »

sudhirj wrote: post #8
joshklein wrote: post #6

Making sure I understand this: I’m some independent developer working in many languages. I like every project I work on to be inside ~/work/ within a subdir I name based on the project. I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right? I understand this isn’t…

You can put any project anywhere you want.

Why is this inaccurate? Go modules allows you to put any Go project anywhere on your machine and have it work fine - what am I missing?

Re: Using Go Modules

#112

Post by qalmakka »

apta wrote: post #96
weberc2 wrote: post #60

Earlier quoted context omitted.

Go's modules are quite a lot nicer than Java's or Python's dependency management / build tools. JavaScript only recently got its act together. Can't speak to Ruby, but Rust is the only one that got it right the first time. Dependency management is only recently a "solved problem". > Go me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket.…

Not sure what you're talking about, Java's dependency management system is strictly superior. Most important software is quite a claim as well.

It could be, but also every time I start a Gradle build I can get up and go brew some coffee, drink some and then come back to see it's still building, so it's not without its flaws.

Re: Using Go Modules

#113

Post by [deleted] »

wiiittttt wrote: post #86
jrockway wrote: post #9

Earlier quoted context omitted.

It does not put modules in GOPATH, at least not where you'd normally find them. Pre-modules github.com/foo/bar would be in $GOPATH/src/github.com/foo/bar. Now they are in $GOPATH/pkg/mod/... (... being based on the URL with some handling for versions and characters that don't work well in filesystems, I don't know the exact details). The main problems I've had with go modules are fast-and-loose upstreams that happily…

I think "go get" will only grab the latest tag. If that commit an hour doens't have a new tag, it won't see anything to update.

[deleted]

Re: Using Go Modules

#114

Post by fiatjaf »

jerf wrote: post #54
fiatjaf wrote: post #42

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,…

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.

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.

Re: Using Go Modules

#115

Post by fiatjaf »

jerf wrote: post #54
fiatjaf wrote: post #42

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,…

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.

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.)

Re: Using Go Modules

#116

Post by fiatjaf »

weberc2 wrote: post #61
fiatjaf wrote: post #42

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! 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…

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.

Re: Using Go Modules

#117

Post by jerf »

fiatjaf wrote: post #115
jerf wrote: post #54

Earlier quoted context omitted.

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.

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.)

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.

Re: Using Go Modules

#118

Post by apta »

qalmakka wrote: post #112
apta wrote: post #96

Earlier quoted context omitted.

Not sure what you're talking about, Java's dependency management system is strictly superior. Most important software is quite a claim as well.

It could be, but also every time I start a Gradle build I can get up and go brew some coffee, drink some and then come back to see it's still building, so it's not without its flaws.

Ironically, I do the same with golang at my current employer. Build times are nowhere near as what's hyped. Much closer to Java, and in fact, due to Java's incremental compilation, golang is often slower.

Re: Using Go Modules

#119

Post by apta »

mirceal wrote: post #107
apta wrote: post #93

Earlier quoted context omitted.

It's how basically the entire language is, they keep reinventing the wheel, only in a subpar way and market it as if it's some breakthrough, and people who don't know better drink the Koolaid. golang wouldn't have gone anywhere if it didn't have the Google name behind it. Did you even notice how verbose the testing code was in that post?

we should form a club or something. we’ll call it the gopher 8th light seekers and drink sparkling water + bitch about go while the rest invent the future. in go :)

hah. What kind of future are you talking about? :P It still seems that Java and C# and python are dominant in their respective areas, and golang being relegated to devops stuff, those guys can deal with all the shortcomings of the language because they don't know better, but at least it's not infiltrating other areas. Ironic that the golang authors wrote it as a C++ replacement and it completely flopped there, just shows how out of touch from reality they are.

Re: Using Go Modules

#120

Post by weberc2 »

apta wrote: post #118
qalmakka wrote: post #112

Earlier quoted context omitted.

It could be, but also every time I start a Gradle build I can get up and go brew some coffee, drink some and then come back to see it's still building, so it's not without its flaws.

Ironically, I do the same with golang at my current employer. Build times are nowhere near as what's hyped. Much closer to Java, and in fact, due to Java's incremental compilation, golang is often slower.

Go has incremental builds as well. I’ve been using it for years and build times are usually a couple seconds; a couple of minutes for huge projects. Are you sure that’s just build time and not some combination of downloading dependencies and/or running tests? How big is your project?
Post reply on HN