> There's no reason to have to write overly abstract code in Java. Whether that's true is beyond the point, which is that the majority of Java code out there i

> There's no reason to have to write overly abstract code in Java. Whether that's true is beyond the point, which is that the majority of Java code out there is in fact overabstracted. That should serve as a hint that there may just be something about Java that does lead to overabstraction. > As for error handling, compare [...] It's much harder to follow what's going on. Making error-handling code paths happen implicitly in the background isn't a straight win. For example, you lose the ability to tell a fallible function from a non-fallible one, especially at the point of calling it. Overall, I find that being able to see all code paths explicitly laid out is better, Go syntax aside. Keep in mind that these examples are tiny, and therefore it's trivial to see how exceptions would implicitly propagate. They become much harder to track as the size and complexity of a codebase grows. > Now add more complex code (e.g. code that does validation or something and you'll see how it blows up) [...] 1 line maps to over 15 lines, I don't think that's readable. I wouldn't say the amount of lines is a great indicator of readability, not unless the difference was in the ballpark of maybe 1 to 100. --- I don't think this code sample is representative: - what would happen to this pretty one-liner if I wanted to catch the exception raised in `i.validate()` and raise a different exception instead? - you can create the .map() function in Go too - the Go code size will not grow linearly as you add more .map()/.filter() calls I feel like a good example of Java code would be much denser, leveraging several expressive language features that Go doesn't have.