GOPATH behaves very, very differently from PYTHON_PATH and CLASSPATH, it is not the same thing at all.

Basically before go 1.11, it was impossible to just do

    git clone ... somedir
    cd somedir
    # build code and run something

You had to instead make sure "somedir" ended up somewhere within a particular deep directory structure. That is what people mean when they say "GOPATH".

> Basically before go 1.11, it was impossible to just do

That's not true. It was always perfectly possible to do that, the code you build just couldn't import any libraries not installed in GOPATH. AIUI that is exactly the same as in other languages.

Our git repo for a backend service contains dozens of packages, and many small packages is recommended in go, and they do need to import one another...

I guess it is not all that different from Python, with Python you need to add the source path to PYTHONPATH / sys.path (and often do so at runtime in the entrypoint script). With go you need the "src/github.com/dagss" prefix to the path. Or at least, according to conventions. You are right that it is more similar on a technical level than what I thought.

The ones listed by you apply mostly as library search path, while go compilers required GOPATH to point to the project being compiled.

False.

You can put your code anywhere you want and `go build` and `go run` will work just fine.

It's only third party libraries that have to be in GOPATH, which is exactly a library (well, package) search path.

False only for very small values of code.

ie if your code itself is split into modules, they won't work (as they are imported by their full path, not relatively), and anything in your vendor dir is also ignored when used outside of a GOPATH entry.

Java, Perl, and Python all date back to the '90s. Yeah, that was a commmon pattern in the '90s.