Curious why they didn't pick something like .go to be more out of the way.
I worked on the YCM support for godef, we eventually had to fork the library and rewrite paths since there was no way of pinning to a version within YCM. Libraries written with github paths for `go get` do not play nice with living outside of gopath, and libraries written with relative paths don't work with go get (even though this is something that go could support)
It's fine for a Go project, but this is not a Go project. It should not be forced to change how it works because it wants to contain some Go code.
Go is not like Python, the end result is a binary, not interpreted source code. You can simply write a build script that sets a custom GOPATH inside a temporary folder, pulls all dependencies, builds and pops out a binary ready for use; and you can either discard or save your custom GOPATH anywhere for caching purposes.
Note that this wasn't the only reason we had to fork. Go doesn't (or didn't) provide a way to pin to a dependency, so we would have had to fork anyway, and then rewrite all the paths anyway, so I went the way of using local paths in the fork.
With non-opinionated languages nothing is stopping you from structuring your code the same way.
Some people stated how hard go makes it when you try to have project that utilizes different languages. Another issue is when you try to use a fork of one of library.
Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.
With Go, I can do `go build $project` from anywhere and get a releasable binary in the working directory. I can do `import "$oldproject/$package"` in my new project and start using it immediately. I can use `godef` to jump around all of the Go code installed on my system and quickly drill down all the way to the Go builtins if I need to. I can use `guru` to see all references to a definition across all of the Go packages installed on my system. The list goes on. And I can do all of that from a favorite text editor (and not a huge slow IDE). I never felt so liberated in any other programming environment, and I've used quite a few.
> Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.
Go binaries have only the standard system libraries for dependencies - for all practical purposes they can be considered static. Or you mean something else?
> Some people stated how hard go makes it when you try to have project that utilizes different languages.
I've used links successfully, but maybe my scenarios were not complex enough?
> Another issue is when you try to use a fork of one of library.
Vendor support since 1.6 made this a nonissue; it's now trivial to use forked versions of libraries.
A fork of a library is either identical to the original, or a new library. And you could argue (or rather: I do), that it is a good thing that you need to explicitly specify which one you intend to use.
As I said, being opinionated is great if the opinion matches yours otherwise you might end up fighting it on every step.
ln -s PROJECT_SOURCE_FOLDER $GOPATH/src/
Re the other question: If you don't run a go command with a path name, it doesn't matter what the directory structure is. I have tons of non-go projects in my GOPATH and build them with the usual tools. No issues.
GOPATH=$HOME go get github.com/foo/bar
$HOME/src/github.com/foo/bar
That is, is the root of each go project effected?
I also set GOPATH=$HOME, and all my source code (not only Go) lives in $HOME/src, and I do use git for both Go and non-Go projects (so they have a .git directory in $HOME/src/what/ever/.git), and there's no problem. Why would there be one?
Wellllllllll... until you actually start to write code against JNI, of course. But the project LAYOUT is simple!
JNA[1] makes things much simpler.
https://plus.google.com/u/0/+RobPikeTheHuman/posts/R58WgWwN9...
Oh, that's rich. This from the guy who designed a language where the case of a symbol's name determines the symbol's visibility.
> First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.
> Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory.
> I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.
At least, I can't think of any similar problems that semantically significant casing in Go creates.