[kweingar]

One of the underrated difficulties of learning Java is the fact that it demands separate files for each exported class.

Writing and reading simple Go libraries is a breeze. I’ve written tiny libraries that fit in one file. You can read it linearly, starting at the top and following the logical progression of type declarations, functions, globals, etc.

Whereas with an identical Java library, a reader would be presented with several small files and have no idea where to start reading.

[simiones]

If you really need this, you can always expose all your actual classes as public static class members of a single wrapper class:

  public class Wrapper {
    public static class C1 { }
    public static class C2 { }
  }

  //other module:

  var x = new Wrapper.C1();

[kweingar]

You could do that, but it doesn’t work with interfaces.

The Go style just lets your code live together for easy reading, no problem. You can comfortably fit all of this into one file: a one-function interface, a couple of small functions that take the interface as a parameter, and two implementations of the interface.

Compare this to 3 or 4 tiny Java files. You’d have to guess which one to click on first.

[seer-zig]

Having worked on even medium sized projects in golang, I started to appreciate why Java requires that. The golang code base was a mess, struct declarations and their implementations littered all over the place, making it hard to follow what's going on. You then need and IDE, and hope that those structs do not accidentally implement some random interface because of structural typing.

[peterashford]

Interesting that you mention interfaces. Mostly I like Go, but one of my bugbears is the difficulty of finding out which interfaces are implemented by a type. It's much easier in Java. Java file organisation is more consistent and regular which is a win at scale.