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

61–70 of 124 posts

Re: Using Go Modules

#61

Post by weberc2 »

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

Re: Using Go Modules

#62

Post by presscast »

I haven't been using Go modules, to the point where I only have a vague notion of what they do.

I haven't felt the need for them.

At what point do they become necessary? Which pain-points should I be on the lookout for?

Re: Using Go Modules

#64

Post by felixfbecker »

LukeShu wrote: post #51
mikepurvis wrote: post #26

I'm not an active golang user, but something which gives me pause here is the insistence on a strict 3-number semver. For a commercial entity shipping software which may include upstream components, it's important to have options for maintaining (and versioning) in-house forks of upstream components. This becomes a problem when you fork v1.2.3 from upstream and want to internally release your fixes, but now your inte…

> I like the Debian solution to this, which permits freeform textual suffixes, so that in the hypothetical scenario above, you can release v1.2.3bigco1, v1.2.3bigco2, ... Go also allows freeform textual suffixes, it just needs a `+` in there: v1.2.3+bigco1, v1.2.3+bigco2.

Oh wow, so they are not following semver? In semver everything after + is a build tag that does not "modify" the version (i.e. 1.2.3+a and 1.2.3+b are considered to both be the same version, just e.g. built at different times).

Re: Using Go Modules

#65

Post by sagichmal »

SamWhited wrote: post #49
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…

> The main problems I've had with go modules are fast-and-loose upstreams that happily rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum. This is really irritating. I have the same problem with TLS: every time a malicious actor tries to manipulate my connection and steal my cookies I get an error page and can't do online banking anymore! Sarcasm aside: this is not a proble…

These two things are not comparable.

Re: Using Go Modules

#66

Post by dragonwriter »

SamWhited wrote: post #49
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…

> The main problems I've had with go modules are fast-and-loose upstreams that happily rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum. This is really irritating. I have the same problem with TLS: every time a malicious actor tries to manipulate my connection and steal my cookies I get an error page and can't do online banking anymore! Sarcasm aside: this is not a proble…

From the point of view of someone considering what to use, it's often of fairly minimal significance if a problem comes from the language ecosystem or from the language technology.

Re: Using Go Modules

#67

Post by minieggs »

I've returned to university recently. We're learning Make in one of my classes at the moment ("learning" Make seems so weird to me). When going over dependency graphs I couldn't stop thinking of how awesome `go mod tidy` is.

Re: Using Go Modules

#68

Post by mikepurvis »

felixfbecker wrote: post #64
LukeShu wrote: post #51

Earlier quoted context omitted.

> I like the Debian solution to this, which permits freeform textual suffixes, so that in the hypothetical scenario above, you can release v1.2.3bigco1, v1.2.3bigco2, ... Go also allows freeform textual suffixes, it just needs a `+` in there: v1.2.3+bigco1, v1.2.3+bigco2.

Oh wow, so they are not following semver? In semver everything after + is a build tag that does not "modify" the version (i.e. 1.2.3+a and 1.2.3+b are considered to both be the same version, just e.g. built at different times).

Sounds pretty similar to the Debian scheme actually, which is pretty well thought out: https://www.debian.org/doc/debian-policy/ch-controlfields.ht...

Where semver is ivory tower idealism, Debian is the battle-tested, pragmatic reality.

Re: Using Go Modules

#69

Post by geodel »

weberc2 wrote: post #60
mirceal wrote: post #35

Every mainstream programming language that came out in the last 20 years has already solved this. Java, Javascript, Ruby, Python, Rust, you name it. I am baffled to why Go has not figured this out and are presenting recent developments as some kind of breakthroughs - they are not. To 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. I…

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

> Rust is the only one that got it right the first time.

Not really the first time. They made attempts before. Dumped it along with person who created earlier solution and then developed current solution.

To their credit they identified early that an official solution is essential.

Re: Using Go Modules

#70

Post by Thaxll »

sagichmal wrote: post #65
SamWhited wrote: post #49

Earlier quoted context omitted.

> The main problems I've had with go modules are fast-and-loose upstreams that happily rewrite history. go mod detects this and stops the world, and you have to manually edit go.sum. This is really irritating. I have the same problem with TLS: every time a malicious actor tries to manipulate my connection and steal my cookies I get an error page and can't do online banking anymore! Sarcasm aside: this is not a proble…

These two things are not comparable.

This prevent things like Nodejs package hijacking. I think it's a pretty big deal tbh.
Post reply on HN