Except for how that didn't work for me. Yes, I have a "reverse midas touch" when it comes to technology, but I think that makes me a good UX critic. :-) And even if/when it does work, I detest the whole GOPATH idea. I know the alternatives are not perfect. I know. But still...
Having coded in more than a dozen different languages, I think the Go ecosystem is the easiest I've used - when you look at the entire development and deployment stack.
You're right that GOPATH needs to be set, but is that really any different to having Python, Perl, Ruby, etc JIT's in your PATH env var? And GOPATH is certainly more convenient when it comes to the distribution of program (ie copying the compiled PE / ELF) than having to ensure that you have a Perl et al run time environment (and particularly any required non-standard imports) installed on the destination system.
But Go isn't a JIT / scripting language, so that's probably not a far comparison. So let's compare it to it's closer relatives: C# and Java. Java is just a mess from a UX perspective. It's a mess to install, it's a mess to redistribute. It's just a complete mess compared with Go. C#, however, is a very friendly language to approach as a new developer - if you're writing applications on Windows and for Windows. I will grant you that .NET is open source and cross platform, and that recent reports suggest .NET projects will become more portable in future years, but you still need a Mono runtime on non-Windows platforms. Go compiles it's dependencies into it's binary (hence the size of the binary).
I'm by no means saying Go is perfect, but lots of people have tried to solve the problem you're raising and more often the case is their attempts are less user friendly than Go. Which leads me to think that maybe the minor inconvenience of having to define GOPATH (and it really only needs to be defined once in the entire lifetime of your Go development machine) is a pretty good usability solution.
Last, but certainly not least, the state of the art tooling for Java, the world class GC (and advanced ones like G1), the breadth and depth of its incredible ecosystem, the performance monitoring and extension API, the innovative Quasar library (https://github.com/puniverse/quasar) for concurrency alongside the features and additions in Java 8 pretty much make Java a serious contender for new projects.
If you haven't explored modern Java, I suggest you give it another look.
I haven't, and that's good to hear. But it's still more complicated than Go if just in regards to how you need to be aware of these tools to begin with. Where as Go's behaviour is out-of-the-box.
This is purely from a "this is my first language" angle though. So I'm not to say that the aforementioned Java tooling isn't better than Go's, and in many other ways too.
Maybe (or maybe not) you'll find this[0] useful: touch .gopath in some project directory, your GOPATH and PATH will be set automatically upon cding inside.
Then, work straight on the root for simplest projects or prototyping, or inside src for multi-package projects. In any case, deps will go in src, and you can readily vendor them, or use git submodule, or a simple shell script containing a sequence of "git clone", or not at all. No tool like godep, no import rewriting, no global workspace, per project dependencies, zero overhead.
I concur. This is an easy and efficient solution. We do that in my company with one difference: instead of setting the GOPATH depending on the current working directory, we use a Makefile.
Building your own working Go installation from source is one command, then building a Go project, yours or someone else is one more command.