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

Looking at your program’s structure in Go 1.7

pauladamsmith.com

Post reply on HN
Print view View original

11–20 of 54 posts

Re: Looking at your program’s structure in Go 1.7

#11

Post by grncdr »

bschwindHN wrote: post #8
thewhitetulip wrote: post #3

Earlier quoted context omitted.

If you mean the $GOPATH directory notation, then I beg to differ, it is one of the favorite things about Go for me, because it is the repo which has all my Go code. For other languages I have a `code` folder which has individual language folders and it contains project. Go has it by default.

It's opinionated, and not the good kind. Some people like having simply a `projects` directory with all coding projects inside. For almost any language, I can clone into this directory and run the associated build scripts. But Go has to be special and use a special directory or else it throws a hissy fit. Aside from that, I do enjoy the language a fair amount.

You can always symlink a project located in your GOPATH to your `projects` directory.

Re: Looking at your program’s structure in Go 1.7

#12

Post by rcarmo »

grncdr wrote: post #11
bschwindHN wrote: post #8

Earlier quoted context omitted.

It's opinionated, and not the good kind. Some people like having simply a `projects` directory with all coding projects inside. For almost any language, I can clone into this directory and run the associated build scripts. But Go has to be special and use a special directory or else it throws a hissy fit. Aside from that, I do enjoy the language a fair amount.

You can always symlink a project located in your GOPATH to your `projects` directory.

It's brittle and confusing nonetheless. Having to set up Go on all the machines I use is a pain I could do without.

Re: Looking at your program’s structure in Go 1.7

#13

Post by gernest »

bschwindHN wrote: post #8
thewhitetulip wrote: post #3

Earlier quoted context omitted.

If you mean the $GOPATH directory notation, then I beg to differ, it is one of the favorite things about Go for me, because it is the repo which has all my Go code. For other languages I have a `code` folder which has individual language folders and it contains project. Go has it by default.

It's opinionated, and not the good kind. Some people like having simply a `projects` directory with all coding projects inside. For almost any language, I can clone into this directory and run the associated build scripts. But Go has to be special and use a special directory or else it throws a hissy fit. Aside from that, I do enjoy the language a fair amount.

You can make a sub directory of your `projects` your GOPATH.

Something like `projects/go`

I have multiple GOPATH for personal reasons and use long running tmux sessions which exports the different GOPATH.

Re: Looking at your program’s structure in Go 1.7

#14

Post by Manishearth »

thewhitetulip wrote: post #3
deallocator wrote: post #2

I must admit I was kind of hoping they'd fixed their horrible requirements for your directory structure, interesting article nonetheless

If you mean the $GOPATH directory notation, then I beg to differ, it is one of the favorite things about Go for me, because it is the repo which has all my Go code. For other languages I have a `code` folder which has individual language folders and it contains project. Go has it by default.

This forces me to use a single clone. I can't work on multiple features simultaneously in different build dirs.

This is incompatible with path dependencies. When I was working on the YCM goto support for Go I had to rewrite all the imports in godef to be path imports because you can't go build packages with github deps outside of gopath. This rewriting had to be done in each file (and forced us to fork the package).

We wanted to use godef as a local folder because YCM wants to be able to pin to a version, usually via a submodule. `go get ` will be affected by silent updates.

Having everything in $GOPATH has the advantage that all your go code is in one place, but it's not much of an advantage because it's not flat -- you have to `cd github.com//` whereas my regular `code` folder has a flat structure, with subfolders only for special cases (e.g. projects with multiple linked repos or whatever).

There are tons of disadvantages, which totally overshadow the minor advantage of automatically giving you a `code` folder -- something which is super easy to do without the "help" of GOPATH.

Fortunately a lot of these things get solved by vendoring, glide, and friends. Bare GOPATH is still terrible.

Re: Looking at your program’s structure in Go 1.7

#15

Post by mappu »

deallocator wrote: post #2

I must admit I was kind of hoping they'd fixed their horrible requirements for your directory structure, interesting article nonetheless

I've come around to GOPATH after hating it originally. It forces you to be somewhat explicit about your package relationships, the package's name, how it finds everything it imports, and how other packages see it. It's doubly important in a language where packages are the compiler's translation unit. The fact is that every language has these problems, GOPATH only makes you confront them - in a standard way, whereas in other languages, you would run into and make a different ad-hoc solution for every project.

C++ is a great example of a model to avoid (pkg-config handles dependencies, except use autoconf for crossplatform, except cmake is newer and supports windows, except then you should use cmake modules instead of p-c, not to mention qt having its own qmake, ...).

Chaining GOPATHs with : can be very useful (just like PATH).

You can use `gb` if you want a "typical" one-folder-per-project workflow.

Re: Looking at your program’s structure in Go 1.7

#16

Post by mappu »

Spiritus wrote: post #4
thewhitetulip wrote: post #3

Earlier quoted context omitted.

If you mean the $GOPATH directory notation, then I beg to differ, it is one of the favorite things about Go for me, because it is the repo which has all my Go code. For other languages I have a `code` folder which has individual language folders and it contains project. Go has it by default.

That's what sucks though. I don't want a "gocode" folder and a "code" folder. It also doesn't fit very well in a monorepo with mixed languages. We had a small benchmark tool written in Go. And people simply couldn't build it, they always came to me after banging their head trying. This is basically what all of them did: $ cd $ git clone $ cd $ go build And obviously it failed because it wasn't in a "src" folder (it w…

Consider checking in the whole gopath to the VCS, and supply a makefile that calls `GOPATH=$(pwd) go build`.

You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.

Re: Looking at your program’s structure in Go 1.7

#17

Post by lloeki »

bschwindHN wrote: post #8
thewhitetulip wrote: post #3

Earlier quoted context omitted.

If you mean the $GOPATH directory notation, then I beg to differ, it is one of the favorite things about Go for me, because it is the repo which has all my Go code. For other languages I have a `code` folder which has individual language folders and it contains project. Go has it by default.

It's opinionated, and not the good kind. Some people like having simply a `projects` directory with all coding projects inside. For almost any language, I can clone into this directory and run the associated build scripts. But Go has to be special and use a special directory or else it throws a hissy fit. Aside from that, I do enjoy the language a fair amount.

I use a `.gopath` file and some small shell support[0] to just `cd` into a go workspace among many. That said, the "clone and be done" approach is something I miss sometimes.

[0]: https://github.com/lloeki/dotfiles/blob/master/shell/go

Re: Looking at your program’s structure in Go 1.7

#18

Post by themartorana »

rcarmo wrote: post #12
grncdr wrote: post #11

Earlier quoted context omitted.

You can always symlink a project located in your GOPATH to your `projects` directory.

It's brittle and confusing nonetheless. Having to set up Go on all the machines I use is a pain I could do without.

Then don't? This is just being opinionated in the other direction and declaring yours the right one.

Re: Looking at your program’s structure in Go 1.7

#19

Post by travisby »

Spiritus wrote: post #4
thewhitetulip wrote: post #3

Earlier quoted context omitted.

If you mean the $GOPATH directory notation, then I beg to differ, it is one of the favorite things about Go for me, because it is the repo which has all my Go code. For other languages I have a `code` folder which has individual language folders and it contains project. Go has it by default.

That's what sucks though. I don't want a "gocode" folder and a "code" folder. It also doesn't fit very well in a monorepo with mixed languages. We had a small benchmark tool written in Go. And people simply couldn't build it, they always came to me after banging their head trying. This is basically what all of them did: $ cd $ git clone $ cd $ go build And obviously it failed because it wasn't in a "src" folder (it w…

Take a look at [gvm](https://github.com/moovweb/gvm) I create (similar to a python virtualenv) a pkgset, and then use `linkthis` to link my current directory as a certain path in my gopath. You could do it yourself with symlinks, but I've been loving the tool for other things it provides, too (like easy access to new versions).

You can feel free to have any repo path you want :D

Re: Looking at your program’s structure in Go 1.7

#20

Post by jacques_chester »

mappu wrote: post #15
deallocator wrote: post #2

I must admit I was kind of hoping they'd fixed their horrible requirements for your directory structure, interesting article nonetheless

I've come around to GOPATH after hating it originally. It forces you to be somewhat explicit about your package relationships, the package's name, how it finds everything it imports, and how other packages see it. It's doubly important in a language where packages are the compiler's translation unit. The fact is that every language has these problems, GOPATH only makes you confront them - in a standard way, whereas i…

GOPATH is an obnoxious neighbour. Most other systems try to play nice.

> The fact is that every language has these problems

Other languages solve them with proper module or library systems.

Rubygems + Bundler is still the standout in this field. Based on my day job, bundler still better at the basic job of "get the stuff I need" and "keep the stuff I need" than any of Pip, NPM, Godep, Composer, Conda and I forget the rest.

> whereas in other languages, you would run into and make a different ad-hoc solution for every project.

It depends on the language. Ruby and NodeJS have clearly dominant single systems. Rust has one by design. Python is a bit of a mess but Pip seems dominant, with Conda for scientific packages. PHP has Composer, which makes a lot of things tolerable, but not great. Go package managers are not really settled, between Godep, Go vendoring and Glide.

Post reply on HN