Assembler is simple like lego is simple: the basics are tremendously easy to understand but the distance between the basic elements and the problems you're trying to solve is very large.
The more 'batteries included' something is the more time you'll spend learning about the eco-system and less about the language per-se.
I don't think that's a fair assessment of Java. The full specification for version 8 is actually 788 pages, so 500 more than C, but you could reasonably argue that of those at least 100 are dedicated to specify what in C is simply undefined behavior and probably another 100 are dedicated to the memory model. The other 300 hundred would be a reasonable overhead for specifying classes and class loading.
You can say a lot of bad things about Java, but it could very well be the best specified language around; the spec is actually very readable, leaves no room for doubt and actually treats that thing called multithreading that still has no citizenship in the C language. You can't say that of a lot of languages.
EDIT:
I took the time of checking the C11 standard PDF (actually the latest available draft, as the ISO asserts copyright on the standard and you can't get it for free). It's 701 pages. But at least C11 has <threads.h>.
The C standard library was a relatively small affair reflective of the way UNIX was built, a couple of well thought out interfaces combined with a lot of freedom (and enough rope to hang yourself several times over).
The Java standard library was absolutely huge and extremely hard to make headway in because each and every part of it seemed to be designed by a committee rather than by an individual (or two).
The x86 set, well, let's not go there, it's just too painful.
And assembly is simple as in 'primitive'. The atoms of assembler are instructions, and even they may be clustered into only a few groups i.e. arithmetic, branch.
I find the resistance to learning assembler is mostly fear. When debugging I very often resort to assembler display, even for machines that I'm not familiar with. I can learn the gist of it in a few minutes just by looking at a little generated code. And there's nothing like the actual machine instructions to find what really caused an exception.
Not necessary. As a young programmer who did not grow up in the java dominated world of 1990-2008.
I took one look at Java and noped the fuck out.
I found C to be more useful.
But its hard to beat the simplicity of java-script.
I disliked java after school and was convinced I was hopeless so I didn't even bother to apply for Java jobs. Then I was recruited into a Java position and picked up the necessary skills to work during my first 4 days and improved steadily from there, but it only worked for me because I was on a good team.
Now it is me who helps people using Java more efficiently : )
