8 ms·

Go 1.11 got me to stop ignoring Go

119 points by waits 8y ago

neduma 8y ago
GOPATH issues - Elaborate more?
- ofrzeta 8y ago
  I was about to ask the same, then after some thinking about it, came to the conclusion that he doesn't like to be forced to save all Go libraries under $GOPATH. Now with Go 1.11 you can have "modules" that you can put all over the place. Much more freedom, right? :) https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules
- 2trill2spill 8y ago
  Apparently too lazy to set an environment variable. I found GOPATH annoying but not using Golang simply for that seems absurd to me.
  - ofrzeta 8y ago
    That's not the point: https://news.ycombinator.com/item?id=18178987 https://news.ycombinator.com/item?id=18178987
    - 2trill2spill 8y ago
      And just what point is that? The article states that "You see, GOPATH crossed a line. " Doesn't explain what that line is and then goes on to say that Golang is an awesome and simple language.
      - really_operator 8y ago
        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."
        2trill2spill 8y ago
        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 8y ago
        [deleted]
        ModernMech 8y ago
        Sure, but there are 100 other languages out there that do the same thing as Go but don't have an opinion about the organization of my system. I'd rather just use one of those, and really I don't think I'm missing out on much by not using Go.
        AnimalMuppet 8y ago
        Where I want to keep my code is not one of the things I grant the language the right to dictate - even if the code is written in that language.
  - nerdponx 8y ago
    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 didn’t integrate with my workflow, I (rightfully) wouldn’t care.
    - deleted 8y ago
      [deleted]
  - Anderkent 8y ago
    Toggling GOPATH between projects is a huge pain, it's not as simple as set it once and forget it.
- pdpi 8y ago
  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.
  - ramenmeal 8y ago
    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?
    - pdpi 8y ago
      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.
  - codetrotter 8y ago
    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.
- jrockway 8y ago
  Your go code has to live in go's directory structure. If your project is github.com/jrockway/whatever, then your source code must live in ~/go/src/github.com/jrockway/whatever/<go files>. There is no other place you can put it (though you can change ~/go to something else by setting $GOPATH in your environment). I assume what upsets people is that everything in go is in a global namespace. So if you have ~/foo-project with some go in it, that doesn't work; you can't import things from there and the compiler won't build it. Instead you have to position it in the "global" ~/go/src for anything to work. I used to teach Perl classes and people were equally upset about the concept of @INC. They did not want to manage packages that way, and the programming language did not give them a choice. This is very off-putting to some people. (Me, I don't care. Not having 8000 configuration options to let the compiler find some github project I'm using is wonderful, even if having to cd go; cd src; cd github.com; cd jrockway; cd project; is kind of a lot of typing to get to the thing you're working on. I have a bash alias to get there ;)
  - weberc2 8y ago
    One nit: it's not "global" because it comes from $GOPATH. If you want, you can create a project like this: `~/myproject/src/app/main.go` and it will work fine so long as you set `GOPATH=$HOME/myproject` for your current shell.
    - raziel2p 8y ago
      It's not that trivial in my experience. I tried hacking my shell so that the `go` command would automatically set GOPATH for me, but then I also had to set GOBIN for some reason, and even then I had to move my repository from ~/code/myproject to ~/code/myproject/src/github.com/myuser/myproject - which is just hugely unnecessary.
  - malingo 8y ago
    > cd go; cd src; cd github.com; cd jrockway; cd project; is kind of a lot of typing to get to the thing you're working on. I have a bash alias to get there In addition to your bash alias for navigation, you can use the `autocd` option of bash so that from your home directory you can say `cd /project`. You can also use the CDPATH variable for quick navigation into a deep directory structure like that.
sonaltr 8y ago
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. to the point that all my go projects are now organized as `project_name/go/src/github.com/username/project_name` as an example. This was really really annoying to say the least.
- divan 8y ago
  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.
  - mtrn 8y ago
    I have been using something similar to ~/site/user/project for years and it worked well so far.
    - merb 8y ago
      me, too. Personal projects: ~/projects/USER/NAMESPACE/PROJECT Company projects: ~/projects/COMPANY_SLUG/NAMESPACE/PROJECT
- zzzcpan 8y ago
  Is it really that hard to solve bad UX of GOPATH? When Go 1.0 came out I remember I couldn't care less about Rob Pike's thoughts on GOPATH and GOROOT and just made a tiny wrapper for go tool that was looking for src/ directory in my tree to populate GOPATH, starting with the current directory (sort of like git does with .git/ directory). And for GOROOT I used a path relative to the wrapper itself. If you are investing time into learning a new language anyway, these things take very little time in comparison and definitely worth it.
symmitchry 8y ago
> 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?
- weberc2 8y ago
  IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):
  - Franciscouzo 8y ago
    You can choose to use: def my_very_very_very_very_very_long_function_name( self, param1, param2): ...
    - weberc2 8y ago
      Ah, my mistake.
  - scott_s 8y ago
    Looking at it (https://www.python.org/dev/peps/pep-0008/ 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.
  - rand_r 8y ago
    My preference is to do this, which I think is quite nice and easy to work with: def my_very_very_very_very_very_long_function_name( self, param1, param2, ): do_it() # function body here.
    - blueprint 8y ago
      Yup this. It works perhaps even more nicely in languages that have braces and return types, e.g. func some_name( arg: Type, arg2: Type ) -> RetVal { … }
tingletech 8y ago
I guess go 1.11 introduced a modules experimental feature as an alternative to `GOPATH` > Go 1.11 adds preliminary support for a new concept called “modules,” an alternative to GOPATH with integrated support for versioning and package distribution. Using modules, developers are no longer confined to working inside GOPATH, version dependency information is explicit yet lightweight, and builds are more reliable and reproducible. https://golang.org/doc/go1.11#modules https://golang.org/doc/go1.11#modules
paxy 8y ago
I have used goinstall, go get (in GOPATH), godep, dep, multiple GOPATHs, symlinks, git submodules and lots more to figure out dependencies in Go, and modules is FINALLY something that actually makes sense.
sdinsn 8y ago
Server is down?
brandur 8y ago
A few years into using Go, I have mixed feelings about `GOPATH`. On one hand, I can see the author's frustration in that it was always incredibly presumptuous of the language's authors to dictate how its users should organize their hard drives, and more so it feels like exactly the type of arrogance that people tend to attribute to the Go's core and community. Also, having helped a number of people now through their early days of the language it's also the one biggest thing by far that reliably confuses every single person. And I mean everyone — from first time programmers all the way up to people who've been in the industry for decades and are learning Go as their tenth language. Being forced to put files in certain places is incredibly non-intuitive because there's nothing else out there that requires it. I must have sent the Go documentation on workspaces [1] to two dozen different people at this point. But on the other hand, once you've grasped the system and are using it, `GOPATH` is surprisingly not bad. It's always obvious where your dependencies are located and which versions are going to be used to build your project. Even better, it lets you very easily drop into those dependencies and add minor changes or debugging lines if you need to. This can be incredibly useful if you're trying to understand how one of them works or think that that you might have found a bug and trying to verify or patch it. A very powerful feature once you know about it. The new Go modules seem good, and will be a huge improvement in lowering the barrier to entry for Go, but I'll miss the old `GOPATH` style of work at this point. [1] https://golang.org/doc/code.html#Workspaces https://golang.org/doc/code.html#Workspaces
- styfle 8y ago
  As someone who hasn't used Go, it sounds like GOPATH is very similar to an Eclipse IDE Workspace.
  - Cthulhu_ 8y ago
    Now you mention it, it sorta is; I haven't used eclipse, but I've never stopped putting all of my projects into a single folder called "workspace" in my home directory. The main difference would be that all dependencies are also in this folder, instead of e.g. a maven or ivy folder located somewhere else. And a (suggested?) folder structure, not dissimilar to java's package structure, where you'd put your e.g. github.com/user/repo repository into $GOPATH/src/github.com/user/repo. I'm sure there's clever tooling or commandline wizardry that works really well with a structure like that.
throw7 8y ago
But how did Go solve the GOPATH problem? He didn't say.
- really_operator 8y ago
  Go modules FTA: "Go modules are great, and probably the single best module system I’ve used in any programming language. Go 1.11 took my biggest complaint and turned it into one of my biggest compliments." https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules
docker_up 8y ago
My biggest problem with Go is the lack of a constructor. I don't feel that a struct type is good enough to enforce data integrity and as you have a more complex program, you need to know that the object you are being passed has data integrity. With a constructor, I can force data to conform to what I need it to. I can ensure that certain fields are not nil, that they conform to a specific list of values, etc. Because of a lack of a constructor in Go, I can't do that and I need to continuously validate the data, which is annoying and a source of bugs. It can be said that this can be accomplished with interfaces but that's adding a lot of complexity to something that should be a lot easier to handle, in my opinion.
- venantius 8y ago
  By authoring private structs with public constructors, you can get what you want out of this. Gets a bit messy with testing, but not impossible.
  - thanatos_dem 8y ago
    If you have your tests within the same package, they can access the private members of structs directly, which helps avoid some of the mess. If you’re in a different package things aren’t too bad if you have meaningfully abstracted interfaces. And with Go’s duck typing, even if you’re using another package that doesn’t have good abstraction, you can create your own interfaces with the functionality you need for mocking purposes.
- toddkazakov 8y ago
  How about just using the builder pattern?
  - _drFaust 8y ago
    Not familiar with go or that pattern but is this a good example? https://gist.github.com/vaskoz/10073335 https://gist.github.com/vaskoz/10073335
    - 8y ago
jerf 8y ago
If you read over the rest of this thread, you can find opinions ranging from "GOPATH is horrible" to "It's wonderful". And I just want to point out this is pretty good example of how important the marginal improvements can be. Abstractly, you might have a hard time sitting there imagining how for a thousand of your users, improving $ONE_SMALL_FEATURE might flip them from not paying you to paying you, but at scale, yes, such margin-based thinking really is important. Just like you may find it hard to really intuit that going from .75s page rendering to .5s page rendering can have a significant impact on the bottom line for an e-retailer, but, yeah, it does. Just wanted to point this out as a clear example of such an issue, since it doesn't come up very often so cleanly.
jeieo3949 8y ago
Perhaps it’s how it is phrased, but the $GOPATH thing seems odd. EVERY piece of software requires a root path to function from. $GOPATH could be /go or /tmp/go or /projects/go/ All software has a file system structure internal to its needs. Like a lot of things in Go, it makes this implicit status quo plain up and up front.
sebcat 8y ago
Having introduced Golang in a business environment in 2014 and having seen the language solve real problems at that time, at scale, I feel that if your own reason to not use Go is GOPATH... Either Go does not solve any real problems for your use case, or your reasons to use Go is misaligned. GOPATH is really not a problem, but efficient concurrency is. Go made the company I worked for go from 20 deployments for a service to 1 (I/O bound), reducing the costs for that service a lot. If you are willing to let the environment get in between that... Of course, you could have implemented that system using assembler for all I care, but Go really made it possible within that organization, something Java, C and other languages failed at before Go was introduced. N=1, ymmv, &c
- apta 8y ago
  > something Java, C and other languages failed at before Go was introduced. Java's concurrency solutions are just as good, if not better than golang's. Pair that with libraries such as RxJava and you're definitely ahead. I don't see what golang has to offer in that area that the JVM doesn't
  - sebcat 8y ago
    Sounds believable, but at the time we were stuck at 1.6 and had a significant drop in traffic due to JSSE and non-existing support of "modern" TLS Cipher Suites and TLS extensions (we even had problems with SNI, years after introduction)... We were using C because epoll made it possible for us to compete, but the Java reactivex stuff were lagging behind.
    - apta 8y ago
      Moving to a completely different language and platform was easier than moving from Java 6 to Java 8? Why were you stuck on 6 otherwise?
    - dagenix 8y ago
      Go may very well have been through best fit for you. However, saying that Java's problem was that you couldn't upgrade from 1.6 yo 1.8 but you could introduce a completely different language doesn't make much sense to me.
floatboth 8y ago
I actually adopted GOPATH for everything. I use https://github.com/motemen/ghq https://github.com/motemen/ghq to quickly clone non-Go projects into the ~/src/github.com/user/project style paths. But… I don't like Go itself (anymore). It's not just the 'if err != nil', it's more the general attitude/philosophy from which it comes. Go is anti-intellectual, the designers basically don't respect the user. "You're too stupid to use generics/Result<A,B>/monads/whatever" is what it feels like they think of you. Go internals are more infuriating than Go language though… Especially the Plan9-based custom assembler. It truly is a horrific atrocity. I've had to deal with it two times: 1. That assembler does not support all instructions and even addressing modes (!) of amd64, so people have had to create hacks like https://github.com/minio/c2goasm https://github.com/minio/c2goasm to run asm functions without the overhead of cgo. Please actually read that project's README, but tl;dr it assembles your code using a normal assembler and STICKS THE BINARY CODE INTO A GO ASSEMBLY FILE AS HEX CONSTANTS. This hack actually didn't work for me when I tried to use some SIMD code, so I had to resort to cgo with its call overhead. 2. I also tried (and failed) to port the Go runtime to FreeBSD/aarch64. This was the last straw, this is what made me actually hate Go.
xet7 8y ago
Yes, but how to do error handling correctly with Go? My Go code crashes.
haolez 8y ago
Side note: I really liked the design of his blog.

119 points by waits 8y ago

neduma 8y ago

GOPATH issues - Elaborate more?

ofrzeta 8y ago
I was about to ask the same, then after some thinking about it, came to the conclusion that he doesn't like to be forced to save all Go libraries under $GOPATH. Now with Go 1.11 you can have "modules" that you can put all over the place. Much more freedom, right? :) https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules
2trill2spill 8y ago
Apparently too lazy to set an environment variable. I found GOPATH annoying but not using Golang simply for that seems absurd to me.
- ofrzeta 8y ago
  That's not the point: https://news.ycombinator.com/item?id=18178987 https://news.ycombinator.com/item?id=18178987
  - 2trill2spill 8y ago
    And just what point is that? The article states that "You see, GOPATH crossed a line. " Doesn't explain what that line is and then goes on to say that Golang is an awesome and simple language.
    - really_operator 8y ago
      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."
      - 2trill2spill 8y ago
        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 8y ago
        [deleted]
        ModernMech 8y ago
        Sure, but there are 100 other languages out there that do the same thing as Go but don't have an opinion about the organization of my system. I'd rather just use one of those, and really I don't think I'm missing out on much by not using Go.
        AnimalMuppet 8y ago
        Where I want to keep my code is not one of the things I grant the language the right to dictate - even if the code is written in that language.
- nerdponx 8y ago
  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 didn’t integrate with my workflow, I (rightfully) wouldn’t care.
  - deleted 8y ago
    [deleted]
- Anderkent 8y ago
  Toggling GOPATH between projects is a huge pain, it's not as simple as set it once and forget it.
pdpi 8y ago
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.
- ramenmeal 8y ago
  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?
  - pdpi 8y ago
    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.
- codetrotter 8y ago
  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.
jrockway 8y ago
Your go code has to live in go's directory structure. If your project is github.com/jrockway/whatever, then your source code must live in ~/go/src/github.com/jrockway/whatever/<go files>. There is no other place you can put it (though you can change ~/go to something else by setting $GOPATH in your environment). I assume what upsets people is that everything in go is in a global namespace. So if you have ~/foo-project with some go in it, that doesn't work; you can't import things from there and the compiler won't build it. Instead you have to position it in the "global" ~/go/src for anything to work. I used to teach Perl classes and people were equally upset about the concept of @INC. They did not want to manage packages that way, and the programming language did not give them a choice. This is very off-putting to some people. (Me, I don't care. Not having 8000 configuration options to let the compiler find some github project I'm using is wonderful, even if having to cd go; cd src; cd github.com; cd jrockway; cd project; is kind of a lot of typing to get to the thing you're working on. I have a bash alias to get there ;)
- weberc2 8y ago
  One nit: it's not "global" because it comes from $GOPATH. If you want, you can create a project like this: `~/myproject/src/app/main.go` and it will work fine so long as you set `GOPATH=$HOME/myproject` for your current shell.
  - raziel2p 8y ago
    It's not that trivial in my experience. I tried hacking my shell so that the `go` command would automatically set GOPATH for me, but then I also had to set GOBIN for some reason, and even then I had to move my repository from ~/code/myproject to ~/code/myproject/src/github.com/myuser/myproject - which is just hugely unnecessary.
- malingo 8y ago
  > cd go; cd src; cd github.com; cd jrockway; cd project; is kind of a lot of typing to get to the thing you're working on. I have a bash alias to get there In addition to your bash alias for navigation, you can use the `autocd` option of bash so that from your home directory you can say `cd /project`. You can also use the CDPATH variable for quick navigation into a deep directory structure like that.

sonaltr 8y ago

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. to the point that all my go projects are now organized as `project_name/go/src/github.com/username/project_name` as an example. This was really really annoying to say the least.

divan 8y ago
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.
- mtrn 8y ago
  I have been using something similar to ~/site/user/project for years and it worked well so far.
  - merb 8y ago
    me, too. Personal projects: ~/projects/USER/NAMESPACE/PROJECT Company projects: ~/projects/COMPANY_SLUG/NAMESPACE/PROJECT
zzzcpan 8y ago
Is it really that hard to solve bad UX of GOPATH? When Go 1.0 came out I remember I couldn't care less about Rob Pike's thoughts on GOPATH and GOROOT and just made a tiny wrapper for go tool that was looking for src/ directory in my tree to populate GOPATH, starting with the current directory (sort of like git does with .git/ directory). And for GOROOT I used a path relative to the wrapper itself. If you are investing time into learning a new language anyway, these things take very little time in comparison and definitely worth it.

symmitchry 8y ago

> 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?

weberc2 8y ago
IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):
- Franciscouzo 8y ago
  You can choose to use: def my_very_very_very_very_very_long_function_name( self, param1, param2): ...
  - weberc2 8y ago
    Ah, my mistake.
- scott_s 8y ago
  Looking at it (https://www.python.org/dev/peps/pep-0008/ 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.
- rand_r 8y ago
  My preference is to do this, which I think is quite nice and easy to work with: def my_very_very_very_very_very_long_function_name( self, param1, param2, ): do_it() # function body here.
  - blueprint 8y ago
    Yup this. It works perhaps even more nicely in languages that have braces and return types, e.g. func some_name( arg: Type, arg2: Type ) -> RetVal { … }

tingletech 8y ago

I guess go 1.11 introduced a modules experimental feature as an alternative to `GOPATH` > Go 1.11 adds preliminary support for a new concept called “modules,” an alternative to GOPATH with integrated support for versioning and package distribution. Using modules, developers are no longer confined to working inside GOPATH, version dependency information is explicit yet lightweight, and builds are more reliable and reproducible. https://golang.org/doc/go1.11#modules https://golang.org/doc/go1.11#modules

paxy 8y ago

I have used goinstall, go get (in GOPATH), godep, dep, multiple GOPATHs, symlinks, git submodules and lots more to figure out dependencies in Go, and modules is FINALLY something that actually makes sense.

sdinsn 8y ago

Server is down?

brandur 8y ago

A few years into using Go, I have mixed feelings about `GOPATH`. On one hand, I can see the author's frustration in that it was always incredibly presumptuous of the language's authors to dictate how its users should organize their hard drives, and more so it feels like exactly the type of arrogance that people tend to attribute to the Go's core and community. Also, having helped a number of people now through their early days of the language it's also the one biggest thing by far that reliably confuses every single person. And I mean everyone — from first time programmers all the way up to people who've been in the industry for decades and are learning Go as their tenth language. Being forced to put files in certain places is incredibly non-intuitive because there's nothing else out there that requires it. I must have sent the Go documentation on workspaces [1] to two dozen different people at this point. But on the other hand, once you've grasped the system and are using it, `GOPATH` is surprisingly not bad. It's always obvious where your dependencies are located and which versions are going to be used to build your project. Even better, it lets you very easily drop into those dependencies and add minor changes or debugging lines if you need to. This can be incredibly useful if you're trying to understand how one of them works or think that that you might have found a bug and trying to verify or patch it. A very powerful feature once you know about it. The new Go modules seem good, and will be a huge improvement in lowering the barrier to entry for Go, but I'll miss the old `GOPATH` style of work at this point. [1] https://golang.org/doc/code.html#Workspaces https://golang.org/doc/code.html#Workspaces

styfle 8y ago
As someone who hasn't used Go, it sounds like GOPATH is very similar to an Eclipse IDE Workspace.
- Cthulhu_ 8y ago
  Now you mention it, it sorta is; I haven't used eclipse, but I've never stopped putting all of my projects into a single folder called "workspace" in my home directory. The main difference would be that all dependencies are also in this folder, instead of e.g. a maven or ivy folder located somewhere else. And a (suggested?) folder structure, not dissimilar to java's package structure, where you'd put your e.g. github.com/user/repo repository into $GOPATH/src/github.com/user/repo. I'm sure there's clever tooling or commandline wizardry that works really well with a structure like that.

throw7 8y ago

But how did Go solve the GOPATH problem? He didn't say.

really_operator 8y ago
Go modules FTA: "Go modules are great, and probably the single best module system I’ve used in any programming language. Go 1.11 took my biggest complaint and turned it into one of my biggest compliments." https://github.com/golang/go/wiki/Modules https://github.com/golang/go/wiki/Modules

docker_up 8y ago

My biggest problem with Go is the lack of a constructor. I don't feel that a struct type is good enough to enforce data integrity and as you have a more complex program, you need to know that the object you are being passed has data integrity. With a constructor, I can force data to conform to what I need it to. I can ensure that certain fields are not nil, that they conform to a specific list of values, etc. Because of a lack of a constructor in Go, I can't do that and I need to continuously validate the data, which is annoying and a source of bugs. It can be said that this can be accomplished with interfaces but that's adding a lot of complexity to something that should be a lot easier to handle, in my opinion.

venantius 8y ago
By authoring private structs with public constructors, you can get what you want out of this. Gets a bit messy with testing, but not impossible.
- thanatos_dem 8y ago
  If you have your tests within the same package, they can access the private members of structs directly, which helps avoid some of the mess. If you’re in a different package things aren’t too bad if you have meaningfully abstracted interfaces. And with Go’s duck typing, even if you’re using another package that doesn’t have good abstraction, you can create your own interfaces with the functionality you need for mocking purposes.
toddkazakov 8y ago
How about just using the builder pattern?
- _drFaust 8y ago
  Not familiar with go or that pattern but is this a good example? https://gist.github.com/vaskoz/10073335 https://gist.github.com/vaskoz/10073335
  - 8y ago

jerf 8y ago

If you read over the rest of this thread, you can find opinions ranging from "GOPATH is horrible" to "It's wonderful". And I just want to point out this is pretty good example of how important the marginal improvements can be. Abstractly, you might have a hard time sitting there imagining how for a thousand of your users, improving $ONE_SMALL_FEATURE might flip them from not paying you to paying you, but at scale, yes, such margin-based thinking really is important. Just like you may find it hard to really intuit that going from .75s page rendering to .5s page rendering can have a significant impact on the bottom line for an e-retailer, but, yeah, it does. Just wanted to point this out as a clear example of such an issue, since it doesn't come up very often so cleanly.

jeieo3949 8y ago

Perhaps it’s how it is phrased, but the $GOPATH thing seems odd. EVERY piece of software requires a root path to function from. $GOPATH could be /go or /tmp/go or /projects/go/ All software has a file system structure internal to its needs. Like a lot of things in Go, it makes this implicit status quo plain up and up front.

sebcat 8y ago

Having introduced Golang in a business environment in 2014 and having seen the language solve real problems at that time, at scale, I feel that if your own reason to not use Go is GOPATH... Either Go does not solve any real problems for your use case, or your reasons to use Go is misaligned. GOPATH is really not a problem, but efficient concurrency is. Go made the company I worked for go from 20 deployments for a service to 1 (I/O bound), reducing the costs for that service a lot. If you are willing to let the environment get in between that... Of course, you could have implemented that system using assembler for all I care, but Go really made it possible within that organization, something Java, C and other languages failed at before Go was introduced. N=1, ymmv, &c

apta 8y ago
> something Java, C and other languages failed at before Go was introduced. Java's concurrency solutions are just as good, if not better than golang's. Pair that with libraries such as RxJava and you're definitely ahead. I don't see what golang has to offer in that area that the JVM doesn't
- sebcat 8y ago
  Sounds believable, but at the time we were stuck at 1.6 and had a significant drop in traffic due to JSSE and non-existing support of "modern" TLS Cipher Suites and TLS extensions (we even had problems with SNI, years after introduction)... We were using C because epoll made it possible for us to compete, but the Java reactivex stuff were lagging behind.
  - apta 8y ago
    Moving to a completely different language and platform was easier than moving from Java 6 to Java 8? Why were you stuck on 6 otherwise?
  - dagenix 8y ago
    Go may very well have been through best fit for you. However, saying that Java's problem was that you couldn't upgrade from 1.6 yo 1.8 but you could introduce a completely different language doesn't make much sense to me.

floatboth 8y ago

I actually adopted GOPATH for everything. I use https://github.com/motemen/ghq https://github.com/motemen/ghq to quickly clone non-Go projects into the ~/src/github.com/user/project style paths. But… I don't like Go itself (anymore). It's not just the 'if err != nil', it's more the general attitude/philosophy from which it comes. Go is anti-intellectual, the designers basically don't respect the user. "You're too stupid to use generics/Result<A,B>/monads/whatever" is what it feels like they think of you. Go internals are more infuriating than Go language though… Especially the Plan9-based custom assembler. It truly is a horrific atrocity. I've had to deal with it two times: 1. That assembler does not support all instructions and even addressing modes (!) of amd64, so people have had to create hacks like https://github.com/minio/c2goasm https://github.com/minio/c2goasm to run asm functions without the overhead of cgo. Please actually read that project's README, but tl;dr it assembles your code using a normal assembler and STICKS THE BINARY CODE INTO A GO ASSEMBLY FILE AS HEX CONSTANTS. This hack actually didn't work for me when I tried to use some SIMD code, so I had to resort to cgo with its call overhead. 2. I also tried (and failed) to port the Go runtime to FreeBSD/aarch64. This was the last straw, this is what made me actually hate Go.

xet7 8y ago

Yes, but how to do error handling correctly with Go? My Go code crashes.

haolez 8y ago

Side note: I really liked the design of his blog.