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