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

Problems with Go Get

0x74696d.com

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Problems with Go Get

#51

Post by brudgers »

thruflo wrote: post #17

It's a meta point but the semantic of `go get` is so beautiful I'm profoundly disappointed that the tool isn't usable. Being able to dispatch a co-routine with `go ...` is beautiful. Being able to fetch a dependency with `go get` is just as succinct and expressive. I'm not up on Go language development but imho the world would be a better place if they could fix the behaviour to preserve the syntax!

"go get" is verbose. GOTO is shorter and considerably harmful. Its subtle beauty was even defended by Knuth.

Re: Problems with Go Get

#52

Post by lobster_johnson »

wallyhs wrote: post #46
lobster_johnson wrote: post #40

Earlier quoted context omitted.

That's what I'm doing these days. But it's painful. It means I have to run full commands such as "go install " or "go get ". To install all dependencies, I have to do "go get ". If I want to work on a project that depends on other projects that haven't been pushed to master yet, I have to clone those projects and symlink them in manually. It's pretty painful. Working with certain tools that assume a certain directory…

You omitted that from your comment, but I agree. I was just pointing out the option, because it didn't sound as if you had tried it. I did not mean to endorse anything.

Yeah, sorry. I have been trying different things. Not happy. But at least it seems that I'm not alone in being dissatisfied. It's surprising because Go does a lot of things right, and disappointing because it's such a brake on productivity.

Re: Problems with Go Get

#53

Post by bichiliad »

True story: I was in a group project in a distributed systems class, and we had made a project that relied on a go http routing package (I think it was martini or something). For some reason, my partner's computer wasn't able to present our project, so at the last minute, we cloned it to my computer. Between then and the night before, the router changed it's API, and forced us to do some crazy last-minute adjustments. In retrospect, we probably could have manually reverted that one package's repo, but git is scary to do things with at the last second.

TL;DR: Versioning is important.

Re: Problems with Go Get

#54

Post by tene »

nulltype wrote: post #44
munificent wrote: post #41

Earlier quoted context omitted.

> why do you specify a version range, and not just always specify a precise version? To handle shared constraints. Let's say myapp uses foo and bar, which both use shared_thing. To solve this, we need to pick a single version of shared_thing that both foo and bar work with. If foo and bar have narrow-to-the-point-of-precise constraints like shared_thing 1.2.3+bug-fix, then it's very likely that no version of shared_t…

Thanks for the explanation! I'm not sure I personally want to rely on semantic versioning, but if you have a hierarchy of dependencies like that I see how that would be pretty useful.

How do you arrange to never have any transitive dependencies?

Re: Problems with Go Get

#56

Post by 0x74696d »

aikah wrote: post #32

It's clear to me that Go didn't get package management right,go get doesn't do package management at all. I think today it is the most important thing the go team has to solve.Otherwise, people will end up using different incompatible solutions. Projects need a manifest so that proper dependencies are declared. People who say "just use make",or "just use git submodule" or "X feature of your VCS" are just pushing for…

> now I have to check what VCS feature it uses, wether it uses a shell script, make , or build tool Z to fetch dependencies

The core of my work is on the operations side rather than on development (although I do a good bit of that as well), so my perspective is that this initial overhead is a one-time cost for using a library, and that I can live with that.

> I think it's time go devs acknowledge the fact that there is an serious issue here, instead of resorting to the ususal "you don't need that in go".

Encountering this and a lot of "well this is the way Google does is so we should too" was a big part of what inspired this post.

Re: Problems with Go Get

#57

Post by 0x74696d »

stock_toaster wrote: post #24
kjksf wrote: post #22

While I do agree that go doesn't come with built-in solution for version pinning, this hating on go get is misguided. Most package managements solutions that are popular in other ecosystem (pip for python, npm for node, cpan for perl etc.) combine 2 functions: downloading code and versioning. go get only does the first part: downloading the code. If you ask me they solved the problem better than pip/npm/cpan by getti…

> go get has never claimed to be versioning solution so > while I understand why people make shallow comparisons > to pip/npm/cpan and assume that it does and complain that > it does it badly (including this article), the reality is > that go get is not a versioning tool at all. The claim is that by not also solving versioning, go get is an incomplete tool. Stating that it was never intended to solve versioning is ki…

> The claim is that by not also solving versioning, go get is an incomplete tool. Stating that it was never intended to solve versioning is kind of beside the point.

You've summed up the entire reasoning behind my post more succinctly than I could. Thanks.

Re: Problems with Go Get

#58

Post by 0x74696d »

howeyc wrote: post #7

Makefiles, build: docker build Ugh, more Linux-Only. Don't follow this please. (This isn't necessarily aimed only at blog post, but guys and gals there are other OSs supported by Go than Linux/OSX. Most of the time just having "go get" work is enough. Trust me, I've done it a lot as an outlier. I use FreeBSD and Windows.) What's wrong with using something like party[1], or nut[2]? Or just vendoring in a way that go b…

> Makefiles, build: docker build Ugh, more Linux-Only. Don't follow this please.

Meh. I get your sentiment here, but I build and deploy on Linux and I post about the stuff I work on. I don't post about the Windows stuff that I haven't worked on in years. And I assume a level of intelligence in my readers that they can translate whatever might be generally applicable into their own platform in the same sense that I don't grumble about Raymond Chen's `Old New Thing` not being directly applicable to my own work but still enjoy it.

Re: Problems with Go Get

#59

Post by 0x74696d »

stock_toaster wrote: post #29

Seems like the author is suggesting something very similar to what [gpm][1][2] provides. I use gpm for a few projects, along with a makefile that creates a GOPATH at $(pwd)/_build, and it works fairly well. [1]: http://java.dzone.com/articles/why-gpm-right-go-package [2]: https://github.com/pote/gpm

Yeah, that plus gvp. But if you dig into both they're just shell scripts under the hood (nice ones, though!) and given that I've got a makefile or shell script to build the container, run tests, etc. then adding a third-party tool is just one tiny bit more overhead.
Post reply on HN