[weberc2]

While I do like that Go is ready to learn, I like that it is small enough to hold in my head. Pretty much everything works intuitively, save for a couple surprises. The same goes for its tooling. There is no complex project or package tooling to learn either.

That said, it doesn't have a passable story for sum types or generics, which are important for the kind of programs I write these days. I'm convinced that summertime could build something as simple as Go, but with better abstraction facilities. Ideally this language would look like Rust and compile to Go.

[kuschku]

> There is no complex project or package tooling to learn either.

Question, how do you handle dependencies without them ending up checked in in your git? I’ve had no success yet with go and dependencies, there’s no simple way like in the Java world to just define a list of dependencies and have the built tool automatically fetch them in some dotfolder, and take care of the rest, is there?

[hellcow]

Use dep, which they're planning to add to the official tools like 'go get'. Then add your vendor directory to your gitignore, and you're done.

[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.