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.