[User23]

I’ve heard three main arguments in favor of using Go. First, that it has a standard library that is world class for building a worldwide ads serving network. If your use case is that or something that’s technically similar, then it’s great. Second, Go has extremely limited facilities for abstraction. Frankly, I dislike that about it, but the argument is that forcing programmers to use a quite limited set of abstractions makes code more readable. I have my doubts, but the argument isn’t prima facie absurd. Third, it produces statically linked binaries that you can copy and run on any machine of the same architecture.

[za3faran]

> that it has a standard library that is world class for building a worldwide ads serving network

What does the golang standard lib have for that use case that Java doesn't have, or do better?

> but the argument is that forcing programmers to use a quite limited set of abstractions makes code more readable

There's a good balance. Sure you can probably argue that Scala opens the door for many different ways to write a program. But golang took the extreme opposite approach, resulting in very verbose code that is difficult to decipher. Java has a very solid middle ground here.

[jpgvm]

I agree that Java definitely strikes a middle ground. It has enough features you can write code in the ways you want (generics, first class functions) but not so many you can create unintelligible messes (implicits).

I generally tend to think of Java is "truly general purpose" because it has enough speed/scalability to implement a database while being generally easy enough for beginners to learn and providing enough scope and structure for building big line of business applications (where only really C# competes). Outside of embedded (excluding smart cards) and the browser mono-language you would be hard pressed to find a field that you can't use JVM to effectively solve a problem.

Java I would still call verbose, it's more verbosity than I tolerated when I was greener but I have come to appreciate a certain amount of ceremony isn't necessarily bad - if it helps to efficiently communicate the intent of the programmer.

I guess what I am trying to say is Java is easy to read, easier even than Go IMO because Go's verbosity is in the wrong places, i.e error handling, loop iteration ceremony, struct construction, etc. while Java's is more inherent to class/application structure which does more to communicate intent.

One thing I did like about Go though from a readability perspective though was their take on visibility. By eliminating the public/private/internal visibility modifiers as seen in JVM code it becomes simple at a glance no matter where you are in the codebase if a method is part of a public API or not just based on it's capitalisation.

[User23]

> Java I would still call verbose, it's more verbosity than I tolerated when I was greener but I have come to appreciate a certain amount of ceremony isn't necessarily bad - if it helps to efficiently communicate the intent of the programmer.

In my experience the trick with Java is to use a purpose built editor like Eclipse or IntelliJ. Once you've achieved competence with an appropriate tool the syntax kind of fades from your attention and you focus on the important parts. Kind of like how experienced Lispers using an appropriate editing mode don't really pay much attention to the parentheses.

[jpgvm]

100% agree.

It was tough coming from a VIM only workflow to IntelliJ but I am really glad I toughed out the transition.

The power is in how all the tooling comes together but it requires a certain investment to get there.

[jpgvm]

Yeah those are all good reasons to consider Go.

I think the static binary argument is a bit flat though.

With Java I don't even need to compile for multiple architectures, I can copy a fat-JAR onto any machine with a JVM and it will execute. i.e an artifact with exactly the same hash and no worries about Mac OS X DNS resolver weirdness or CGO nonsense.

[arccy]

but now you have the nonsense of dealing with jvm versions and choosing the right one

[jpgvm]

That is fairly overblown, especially post Java 9 (2017).

Generally speaking you just target a minimum version if you want to not distribute the JVM itself but these days most Java software is backend software, most of which is containerized, packaging the runtime with the code itself.

[cutler]

But bad news if you actually need a decent interface to C libraries.