[mi100hael]

It's not always clear how to do that. Sure, in theory it's possible to manually download JARs, configure your classpath, and run javac. In practice, the wisdom seems to be to replace the old ecosystem with a new ecosystem like Maven -> Gradle or Spring -> Spring Boot.

In comparison, the entire standard build process for a Go program is:

    $ export GOPATH="/path/to/repo" && go get && go build && ./main

No config files with some DSL to learn or handwritten XML, no weird class loader behavior to track down, no tuning memory limits or any of that stuff that is just par for the course in Java.

[paulddraper]

The tooling is a very valid critique.

Like C/C++, javac is just a compiler.

It's not a a dependency resolver, a runtime, a formatter, etc.

go is all of those things.

[vips7L]

The entire build process for java is mvn package. The only xml you encounter in modern java will be your pom.xml. How is that any different from a package.json, go.mod, cargo.toml, or Pipfile?

[mi100hael]

And then I get a jar. Or maybe a war. Or maybe a zip? And maybe it's a fat jar with all dependencies bundled. Or maybe not and I need to fetch a bunch of deps and configure a classpath. And then I need the right JRE wherever I'm going to run it. And then I can run it like 'java -jar'. Or maybe I need a server like Tomcat. Or maybe something else.

And every time you jump into an existing codebase, you need to scrutinize the docs that are hopefully there to figure out particulars of the build/deploy process.

[vips7L]

This is any language in any code base. Even in Go I will need to figure out if go modules, dep, or something else is being used. In rust, does this project produce a bin or rlib? Having options isn't a bad thing.