I don't think that's really true, at least not anymore. It's definitely smaller than C++ or Rust, slightly smaller than C#, but larger than Python, JavaScript, Go.
It is def not slightly smaller than C#, C# is a cool language, but it is definitely well ahead on a road towards becoming the next C++. C# is probably the second or third most complex/feature-full language I know of (not sure whether the list goes from C++, Swift, C#, or the last two reversed), while Java is quite down the list.
Not sure about any objective metric on the other languages, though. Tried to look at ANTLR grammar files for each, but grammar is only one part -- language semantics are not included. (E.g. Rust's grammar is slightly smaller than Java's, yet I don't think many would argue that it is the easier one). JavaScript, while easy on the surface, can actually be quite complex/has many non-idiomatic concepts, e.g. `this` handling, property flags, etc. Python has similar "rabbit holes".
All the weird folders nested into folders, the verbosity, the difficulty to follow logic, all the crazy patterns. I guess you also have all the OOP stuff that doesn’t exist in golang. I always felt like its impossible to write java without a beefy IDE
I don’t know — do you have to know how an engine works to drive a car? While they may not understand at first why they have to write this, I really dislike when people make that 3 words into something impossible to grasp. A good chunk of all programmers have learnt to program by starting with Java. And besides these 3 words, it is a small language (very few keywords), easy, but sufficiently strong type system that will catch most of your problems at compile time, and first and foremost, very well-defined runtime semantics, even when errors happen, all of which help beginners greatly.
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.
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.
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.
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.
I think the point is that this is hard to learn. Whether it’s necessary to learn is a separate question. I think it’s easier to be an effective dev when you do understand how these things work, and designing a language to make it easier to acquire that understanding is good.
Never really thought of that particular keyword soup when I was first learning it. It wasn’t an issue. Grokking Java-style OO was much harder. I probably still don’t grok it.