Kind of, but with more `strings.hasSuffix(...)` and less `new StringComparatorFactory(new StringSubsetComparison(), StringComparisonPositions.END_POSITION, ...`

Give it time, Go is still pretty new and requires reinventing all those wheels and flexibility-allowances. It's already visible in some areas though - e.g. look at the hoops you have to code through to allow decent unit testing of controller-style code. Anything of interest has to be exported and injected, or you simply can't do it. Even Java's significantly better here with its runtime manipulation.

In Java it is string.endsWith(...), not much different.

Ok bad example but you get the idea.

No, Java has become too advanced for the typical Go developer.

Too many features.

It is for me. Could not figure out advanced tools like Maven or gradle. Maybe it was beneath Java experts at Sun/Oracle develop simple cli tool that could compile a java project with one command.

You mean just using javac -sourcepath is too hard?

'gradle build'

Unless the project is very badly configured, that should be all you need to compile it. Now, writing those .gradle files...

Yea, advanced language like Java should have advanced build tools and build files. Go is simplistic so `go build|install|run` just works without IDEs, build files, and external build tools.

Well, yes, if you include the build tool in with your language implementation you do not need external build tools.

Compiling most Java projects is usually as simple as 'brew install maven; mvn package'. Maven does require a build file, but it can also do more than the go utility, such as deploying artifacts in a repository, build distributable tarballs, RPMs, debs, etc.

Maven, like go, largely relies on convention over configuration as well. If you generate a POM file from the standard archetype, you basically drop your files in the right source directory and it will build.

(I am not a fan of Java, but I think a lot of the criticism here is lazy. The first time you use the 'go' tool you have to learn its usage as well: how to separate library code from programs, what are the conventions for package structure, how to avoid API breakage for downstream users, etc.)

> Now, writing those .gradle files...

Gradle build files have confusing syntax. Just knowing which lines have an equals sign and which don't is a bit of work.