4 ms·

Whenever someone says "X is one of the dumbest ideas" there are two possibilities: 1. The person who came up with the idea is actually very stupid. 2. The per

Whenever someone says "X is one of the dumbest ideas" there are two possibilities: 1. The person who came up with the idea is actually very stupid. 2. The person speaking doesn't fully understand the idea, or all applications of it. Guess which option is more commonly true?

iainmerrick 9y ago
Quite often it's just 3. They're obviously exaggerating, but still onto something. Why is GOPATH a good idea? Can you explain it? I guess the intention is to have all the packages you're using side-by-side (including the one you're working on)? That is not obviously a terrible idea, but as Go has more recently adding vendoring support, it clearly doesn't cover all the use cases. If I'm using a third-party package, I almost always want to either install it in /usr/local (via Homebrew, say) for minimal hassle or vendor it into my project so the project is standalone. The GOPATH approach -- having external packages as peers of my project -- feels like a pretty distant third (although admittedly I'm not a Go user). This feedback was given very early on in the development of Go, so the GOPATH behavior could easily have been changed, but clearly the language designers felt it was a good approach. I imagine it's a Plan 9 convention?
- slrz 9y ago
  I don't understand the GOPATH criticism. For your C compiler to find included header files they need to be specified relative to /usr/include (or some other path contained in the list searched by your compiler). For the go build tool to find Go packages they need to be given relative to (an element of) GOPATH (which is a colon-separated list of directories that is searched for Go package sources). To work on your own code inside your home directory while installing other packages using Homebrew, you'd set a GOPATH of $HOME:/usr/local. If you also want to consider packages shipped with the OS, you append a ":/usr" to that. Lots of things work this way: @INC in Perl, sys.path in Python and many more. Why have people such issues understanding this concept when it's called GOPATH?
  - iainmerrick 9y ago
    If I have a hello.c and hello.h in the same directory, and hello.c #includes "hello.h", I can "cc hello.c" and it always works just fine. In Python, you have to add some empty __init__.py files to your project, but once you've done that, local imports work just fine, no environment variables needed. GOPATH is unusual and not like other programming languages. Once again, the two major use cases for imports are "stuff local to my project" and "stuff I've installed". GOPATH covers a third case, "other packages I want to use, that I haven't installed and haven't vendored". That doesn't seem important enough to warrant making "stuff local to my project" irritatingly fiddly. If I download some Go program from Github, even if it has all its dependencies vendored, it doesn't work unless I put it in ~/go or set GOPATH. That's strange! Why wouldn't you want it just to work out of the box, wherever you put it?
rgbrenner 9y ago
I never said any of Golang's developers are stupid. On the contrary, they're clearly smart people. I like golang, and I think it's a great language. But even smart people have bad ideas sometimes, and GOPATH is one of those. I think I fully understand GOPATH.. I've been programming in GO every day for several years. But sure, go ahead and tell me what's so awesome about GOPATH, that can't be achieved by using the current working directory.

iainmerrick 9y ago

Quite often it's just 3. They're obviously exaggerating, but still onto something. Why is GOPATH a good idea? Can you explain it? I guess the intention is to have all the packages you're using side-by-side (including the one you're working on)? That is not obviously a terrible idea, but as Go has more recently adding vendoring support, it clearly doesn't cover all the use cases. If I'm using a third-party package, I almost always want to either install it in /usr/local (via Homebrew, say) for minimal hassle or vendor it into my project so the project is standalone. The GOPATH approach -- having external packages as peers of my project -- feels like a pretty distant third (although admittedly I'm not a Go user). This feedback was given very early on in the development of Go, so the GOPATH behavior could easily have been changed, but clearly the language designers felt it was a good approach. I imagine it's a Plan 9 convention?

slrz 9y ago
I don't understand the GOPATH criticism. For your C compiler to find included header files they need to be specified relative to /usr/include (or some other path contained in the list searched by your compiler). For the go build tool to find Go packages they need to be given relative to (an element of) GOPATH (which is a colon-separated list of directories that is searched for Go package sources). To work on your own code inside your home directory while installing other packages using Homebrew, you'd set a GOPATH of $HOME:/usr/local. If you also want to consider packages shipped with the OS, you append a ":/usr" to that. Lots of things work this way: @INC in Perl, sys.path in Python and many more. Why have people such issues understanding this concept when it's called GOPATH?
- iainmerrick 9y ago
  If I have a hello.c and hello.h in the same directory, and hello.c #includes "hello.h", I can "cc hello.c" and it always works just fine. In Python, you have to add some empty __init__.py files to your project, but once you've done that, local imports work just fine, no environment variables needed. GOPATH is unusual and not like other programming languages. Once again, the two major use cases for imports are "stuff local to my project" and "stuff I've installed". GOPATH covers a third case, "other packages I want to use, that I haven't installed and haven't vendored". That doesn't seem important enough to warrant making "stuff local to my project" irritatingly fiddly. If I download some Go program from Github, even if it has all its dependencies vendored, it doesn't work unless I put it in ~/go or set GOPATH. That's strange! Why wouldn't you want it just to work out of the box, wherever you put it?

rgbrenner 9y ago

I never said any of Golang's developers are stupid. On the contrary, they're clearly smart people. I like golang, and I think it's a great language. But even smart people have bad ideas sometimes, and GOPATH is one of those. I think I fully understand GOPATH.. I've been programming in GO every day for several years. But sure, go ahead and tell me what's so awesome about GOPATH, that can't be achieved by using the current working directory.