I come from originally a PHP background, and for me to do a fraction of what Go can do would require me to go in and mess with php config files and spin up more servers in order to get the performance I need, and with Go that's just not the case.
As author of this article, I can only say that I wrote about Go because I honestly like it, not because I have any agenda.
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.
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?
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.
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.
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.
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.
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.