[kuschku]

I don’t want a vendor directory in the first place, how do I avoid that? I want it to just automatically do its stuff just like maven/gradle/sbt work, and not deal with any damn dependencies. I want it to automatically set the dependency path, and handle incremental compiles.

If people claim it has so much better tooling than Java, then I expect at least it to work as well as Java’s tooling.

[weberc2]

You're confused, Java's tooling is more complex/less intuitive. It doesn't matter where the dependency data lives on your system; it's completely transparent to you.

[kuschku]

> It doesn't matter where the dependency data lives on your system; it's completely transparent to you.

Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it).

Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening.

If I want to add a preprocessor, I import it the same way that I’d import a normal dependency, just with another directive – `compile 'com.jakewharton:butterknife:8.8.1'` vs `annotationProcessor 'com.jakewharton:butterknife-compiler:8.8.1'`.

This is something I really miss in the JS and Go and C and C++ world. It all just works.

[weberc2]

> Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it).

This seems like a ridiculous edge case to optimize for. It's rare and trivially corrected.

> Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening.

You don't have to configure a $GOPATH in Go. If you don't specify it, it defaults to $HOME/go. Just use `dep` to manage your versioned dependencies or `go get` if you're prototyping. Unlike Gradle, there is no scripting language to learn--static binaries and native dependencies are supported with no extra configuration, and everything is fast without a complicated daemon to install.

[hellcow]

I'm trying to understand your complaint.

Obviously you'll need a vendor directory somewhere containing the source code of your dependencies. Maven places them outside the project's root dir (defaults to ~/.m2/repository), whereas Go puts them inside the project's root dir. Tomato-tomato. They have to exist on your system somewhere.

[kuschku]

> They have to exist on your system somewhere.

Yes, but they shouldn’t be something I’d have to ever care about. Whenever I type "build", the build tool should automatically manage the dependencies and invoke the build process.