Live data from Hacker News

Go 1.11 got me to stop ignoring Go

drewdevault.com

21–30 of 79 posts

Re: Go 1.11 got me to stop ignoring Go

#21
post #8
post #2

GOPATH issues - Elaborate more?

Go insists that all of your Go code must live inside of a single hierarchy under $GOPATH. This pretty much forces you to organise files in your system in a very particular way, where the language a project is written in takes precedence over any other organisational concerns, and doesn't play well with, e.g. my setup, where I file my projects in a hierarchy shaped like ~/dev/{personal,$COMPANY,3rdparty}/$PROJECT_NAME…

Symlinks are your friends ;)

Keep the actual directory where Go wants it to be and create a symlink to it in ~/dev/$who/$project.

Next, create a script that you name as “mygo” or whatever (something short and memorable that makes sense to you. I would probably name it as just “g”) and put it in your ~/bin/ and ensure you have ~/bin in your $PATH.

In said script you resolve the real path of your project, cd there and then execute /usr/local/bin/go with the args that your script got:

    #!/usr/bin/env bash

    cd "$( realpath . )"

    /usr/local/bin/go "$@"
So when you are in ~/dev/someclient/someproject/, you run “mygo build” and the script runs “go build” from the real path of the project. (At first I suggested to name your script as just “go”, but I decided that it was probably better to use a non-colliding name instead and so I quickly edited this comment.)

That ought to do it.

I totally agree with you though. I do similar to you — I keep public projects under ~/src/github.com/ctsrc/$project and client projects under ~/src/$client/$project. If it wasn’t for the fact that I don’t write in Go I would be annoyed too.

Re: Go 1.11 got me to stop ignoring Go

#22
post #8

Earlier quoted context omitted.

Go insists that all of your Go code must live inside of a single hierarchy under $GOPATH. This pretty much forces you to organise files in your system in a very particular way, where the language a project is written in takes precedence over any other organisational concerns, and doesn't play well with, e.g. my setup, where I file my projects in a hierarchy shaped like ~/dev/{personal,$COMPANY,3rdparty}/$PROJECT_NAME…

I have multiple different languages and code for multiple companies and have no issues. I guess the issue is that you don't want to include the repo location in the path?

I mean I want to have ~/dev/personal/some_go_project and ~/dev/personal/some_java_project side by side, instead of being forced to move some_go_project to ~/go_dev/some_go_project. Java (and, well, just about every other language I've ever touched) is perfectly ok with this, Go isn't.

Re: Go 1.11 got me to stop ignoring Go

#23
post #7

Earlier quoted context omitted.

Apparently too lazy to set an environment variable. I found GOPATH annoying but not using Golang simply for that seems absurd to me.

You see, GOPATH crossed a line. Go is opinionated, which is fine, but with GOPATH its opinions extended beyond my Go work and into the rest of my system. As a naive new Go user, I was prepared to accept their opinions on faith - but only within their domain. I already have opinions about how to use my computer. I knew Go was cool, but it could be the second coming of Christ, and so long as it was annoying to use and…

[deleted]

Re: Go 1.11 got me to stop ignoring Go

#24
post #15

> I have major gripes with PEP-8, and if you ever see me using it I want you to shoot me in the face. That sounds extreme. I've never heard this before. Why?

IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):

You can choose to use:

    def my_very_very_very_very_very_long_function_name(
            self, param1, param2):
        ...

Re: Go 1.11 got me to stop ignoring Go

#25
post #15

> I have major gripes with PEP-8, and if you ever see me using it I want you to shoot me in the face. That sounds extreme. I've never heard this before. Why?

IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):

Looking at it (https://www.python.org/dev/peps/pep-0008/), that is one of the options, but you could also do:

  def my_very_very_very_very_very_long_function_name(
          self, param1, 
          param2):
      pass
Shrug. Seems okay to me, and preferable to what they say no to.

Re: Go 1.11 got me to stop ignoring Go

#26
post #15

Earlier quoted context omitted.

IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):

You can choose to use: def my_very_very_very_very_very_long_function_name( self, param1, param2): ...

Ah, my mistake.

Re: Go 1.11 got me to stop ignoring Go

#27
post #8

Earlier quoted context omitted.

Go insists that all of your Go code must live inside of a single hierarchy under $GOPATH. This pretty much forces you to organise files in your system in a very particular way, where the language a project is written in takes precedence over any other organisational concerns, and doesn't play well with, e.g. my setup, where I file my projects in a hierarchy shaped like ~/dev/{personal,$COMPANY,3rdparty}/$PROJECT_NAME…

Symlinks are your friends ;) Keep the actual directory where Go wants it to be and create a symlink to it in ~/dev/$who/$project. Next, create a script that you name as “mygo” or whatever (something short and memorable that makes sense to you. I would probably name it as just “g”) and put it in your ~/bin/ and ensure you have ~/bin in your $PATH. In said script you resolve the real path of your project, cd there and…

Sure, there's decent workarounds to solve this problem, but I take it as a general rule that, if I'm fighting against (rather than with) a tool, I'm either using the wrong tool, or I'm using the tool wrong.

If my fight against a language starts at the "I can't put my source code where I want without having to fight it", it's an uphill battle to convince me this is not a "using the wrong tool" scenario, and I'm happy to take my dev time elsewhere.

Re: Go 1.11 got me to stop ignoring Go

#28

> I have major gripes with PEP-8, and if you ever see me using it I want you to shoot me in the face. That sounds extreme. I've never heard this before. Why?

I have major gripes with it too and don't use it unless a project enforces it.

The main ones that get me are the whitespace (4 characters) and restrictive line length (79 characters) rules. They don't work well together, and also don't work well with python's significant whitespace (can't easily break up a line), namespaces, generator expressions, and type hints. All for a subjective formatting decision.

I'll also often see people trying to cram as much as they can into 79 characters with one letter variable names and such while calling that elegant code because it's a "one-liner."

Re: Go 1.11 got me to stop ignoring Go

#29
post #12

I whole heartedly agree with the author. While I disagree with GO's style guide and a ton of other choices - I don't mind following them since that's what the language requires. But it goes past that and wants me to organize everything my working directory just for it - it's absolutely crossing a line. While I didn't stop using Go because of GOPATH, it's one of those things that absolutely annoyed the crap out of me.…

That's funny, but since I started using Go, I now organize all projects under GOPATH, i.e. in `~/src/github.com/user/project`, no matter what language it is in. GOPATH and HOME are almost synonims now.

I find it so much better experience than using tons of `~/Work`, `~/Projects`, `~/Code`, `~/SomeLang/` etc. as I used to have before.

Re: Go 1.11 got me to stop ignoring Go

#30

Earlier quoted context omitted.

He says it in the next sentence. "...but with GOPATH its opinions extended beyond my Go work and into the rest of my system. [...] I already have opinions about how to use my computer."

Not sure I agree with that statement. Yes Golang has an opinion on where it wants you to keep your go code but it dosen't effect the rest of your system, just your go work.

[deleted]
Post reply on HN