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

Keeping your Go modules compatible

blog.golang.org

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Keeping your Go modules compatible

#31

Post by bootlooped »

Thaxll wrote: post #13
naringas wrote: post #12

there's something that I just don't get about golang modules, I don't know what it is but they don't click with me it might well be something tacit that golangers learn from each other directly? or otherwise it's so obvious and simple and I just haven't realized? it feels like it's the kind of thing that just clicks one day possibly after a few years

It's pretty clear and well explained there: https://github.com/golang/go/wiki/Modules On a day to day operation, you need to know 2/3 commands that's it. - go mod init - go mod tidy - go get xxx

I use `go mod vendor` a lot.

Re: Keeping your Go modules compatible

#32

Post by monkeyfacebag »

opqpo wrote: post #4

Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. The language as a whole despite being now universally used as the backbone of cloud native, it honestly looks like it's intentionally designed to be horrible and insulting for anyone with sensible mind. Every obvious right de…

This comment would benefit immensely from a single concrete example. As it is, it scans as bluster.

Re: Keeping your Go modules compatible

#33

Post by swagonomixxx »

ElCampechano wrote: post #30
poorman wrote: post #15

> When you run into a case where you want to add a method to an existing interface, you may be able to follow this strategy. Start by creating a new interface with your new method, or identify an existing interface with the new method. Next, identify the relevant functions that need to support it, type check for the second interface, and add code that uses it. I like this pattern, and I have used it. The issue I have…

How did you solve the pattern of not having generics in the language?

Try this: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

Re: Keeping your Go modules compatible

#34

Post by swagonomixxx »

Thaxll wrote: post #29
jacques_chester wrote: post #23

Earlier quoted context omitted.

> Most of what you describe is the result of having waited ages before implementing it Except we already had godep. It worked. It was in widespread use. > exacerbated by the relatively decent (but not perfect) backward compatibility with pre-modules code. My experience has been that the backwards compatibility has been a nightmare. It forces itself on any downstream repository, whether or not that repository wishes t…

godep was awefuly slow and buggy.

Will have to second this. I didn't find godep more usable than glide, and I find vgo (current Go module implementation) to be far superior to godep.

Re: Keeping your Go modules compatible

#35

Post by closeparen »

littlestymaar wrote: post #25
mseepgood wrote: post #6

Earlier quoted context omitted.

> Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane. https://research.swtch.com/vgo

It's the most over-though versioning system ever actually. It's a rare mixture of NIH syndrome and obsession to a specific theoretical concern. Yes semver dependency management is NP-hard[1], but lawn mowing is NP-hard too, and yet that doesn't seem to stop anyone else! [1] in fact it's only NP-hard if you add an optional aditionnal constraint: that every dependency must have a single instance even if it's a transiti…

Yet asking Glide or Dep to solve semver for a typical medium-sized Go service would peg your CPU fans for an hour or two and usually fail.

Re: Keeping your Go modules compatible

#36

Post by blondin »

mseepgood wrote: post #6
opqpo wrote: post #4

Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. The language as a whole despite being now universally used as the backbone of cloud native, it honestly looks like it's intentionally designed to be horrible and insulting for anyone with sensible mind. Every obvious right de…

> Go modules and the entire package management and versioning system is just embarrassingly horrible. It looks like it was designed by people who have no background in software engineering at all. Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane. https://research.swtch.com/vgo

> Go modules is probably the most well-wrought versioning system for a programming language. The amount of thought that went into it is insane.

appreciated, but i share GP's sentiment.

without the uncalled for bashing though. because package management and versioning is hard. for all the backlash they get, package management in python, ruby, php, nodejs, all makes sense to me!

they make so much sense that, in my opinion, that the situation is akin to picking a side and sticking to it. just like you would for your favorite text editor. you perfectly understand what is going on.

go package management on the other hand makes no intuitive sense!

it took like 3, 4, or 5 long blog posts to explain it to us. and all i got from them is how hard package management truly is. i still can't intuitively do it.

i haven't touched php or nodejs in a while but i will be able to get composer or npm or npx (or whatever it is nowadays) to install something for me, locally or globally. not saying it is done right. what i am saying is i get it!

sorry but something is not right with go modules.

Re: Keeping your Go modules compatible

#37

Post by blondin »

naringas wrote: post #12

there's something that I just don't get about golang modules, I don't know what it is but they don't click with me it might well be something tacit that golangers learn from each other directly? or otherwise it's so obvious and simple and I just haven't realized? it feels like it's the kind of thing that just clicks one day possibly after a few years

same.

go team dropped the ball on this. i feel a sense of non-consensus among themselves on what modules should have been. and it's frustrating that there is no definite documentation either.

maybe one day...

Re: Keeping your Go modules compatible

#38

Post by enjoylife »

I use Go daily and one of the aspects which is always a challenge is equality checking. From the post,

> There is one subtle way a new field can break user code unexpectedly. If all the field types in a struct are comparable—meaning values of those types can be compared with == and != and used as a map key—then the overall struct type is comparable too. In this case, adding a new field of uncomparable type will make the overall struct type non-comparable, breaking any code that compares values of that struct type.

From experience, this is non-trivial to avoid in a long lived codebase.

It’s telling that 99% of the codegen tools used in Go, e.g. protobuf, thrift, Gorm, etc. all output an isEqual method of some kind.

Re: Keeping your Go modules compatible

#39

Post by apta »

enjoylife wrote: post #38

I use Go daily and one of the aspects which is always a challenge is equality checking. From the post, > There is one subtle way a new field can break user code unexpectedly. If all the field types in a struct are comparable—meaning values of those types can be compared with == and != and used as a map key—then the overall struct type is comparable too. In this case, adding a new field of uncomparable type will make…

Anyone who's worked on a large project and code base will appreciate the features proper mature languages like Java or C# offer.

It's ironic that golang was supposedly designed for "programming in the large", but it's just a very bad experience for non-trivial code bases.

Re: Keeping your Go modules compatible

#40

Post by plorkyeran »

closeparen wrote: post #35
littlestymaar wrote: post #25

Earlier quoted context omitted.

It's the most over-though versioning system ever actually. It's a rare mixture of NIH syndrome and obsession to a specific theoretical concern. Yes semver dependency management is NP-hard[1], but lawn mowing is NP-hard too, and yet that doesn't seem to stop anyone else! [1] in fact it's only NP-hard if you add an optional aditionnal constraint: that every dependency must have a single instance even if it's a transiti…

Yet asking Glide or Dep to solve semver for a typical medium-sized Go service would peg your CPU fans for an hour or two and usually fail.

And ask NPM to install a package and it's able to pick a version of all eight hundred dependencies that package pulls in within a few seconds.
Post reply on HN