C# just went through this for C# 10, which I find a waste of resources, optmizing for "Hello World" is not what matters in large scale engineering.
Read the article, the "static trap" is a real thing for new students (on top of all other ceremony). To solve the issue of main being non-static some students will start to put static everywhere as a 'fix' to their initial issue, a day or two later they'll be asking why every student gets the same name (because they have one static variable to keep the student or name objects).
The verbosity of Java also introduces another more serious problem for learning, not only do the students have problems compiling, they also start putting their mind on focusing on syntax instead of logic once they're past the first few problems. The issue of de-programming students from this affliction is waaay too common to be ignored.
I wasn't found of minimal APIs, global usings and implicit Program.cs for C# 10, and share a similar opinion in relation to Java.
No need to try to make it look like JavaScript and Python, each language has its place.
I wanted to delve into Java. And sure enough, my very first thoughts were "wtf is public static void, why does this even matter, and why is print() so weird and long?"
Shit, I ended up finding it easier to get into F# than Java.
Then I got hired for a Java role, which is proof that the universe has a sense of humour.
Which makes the feature kind of pointless. Especially since all teaching materials (and those who have used them for teaching) were saying to just ignore the rest for now and concentrate on
Console.WriteLine("Hello World!");
I've taught C to beginners after the Java class and whilst there are some related problems those students encounter, the extra confusion caused by having main in a class doesn't exist (and doesn't cause as much syntax vs logic confusion later on).
The lecture notes that eventually became this book were their path into discovering C++.
https://www.bertrand.pt/livro/programacao-com-classes-em-c-p...
And then there is the issue with leaky abstractions when the code that gets compiled interfers with the ideal worlds that the compiler injects, and possible confusing error messages get generated.
Like it happens with all guest languages that target the JVM pretending to be Java, and one gets a confusing stack trace only understandable by those with proper Java background.
The problem isn't the set of things students will need to learn, but the order in which they encounter them. Students write a one-file program before they write a two-file one, but because Java is optimised for large programs, today they encounter things like accessibility rules -- which exist to serve large programs -- before they even get to write a very small one. That's the idea of the "on-ramp" in the title -- you end up int the same place, but with a smoother ride.
Both students and teachers who prefer Python to Java as a first language mentioned this "on-ramp" problem as one of the reasons. There are others, and they will be addressed by other enhancements.
BTW, importing other packages and using helper methods does not require knowing about accessibility rules.
> Like it happens with all guest languages that target the JVM pretending to be Java, and one gets a confusing stack trace only understandable by those with proper Java background.
But this is not a "guest language" and we'll need to ensure that stack traces -- which we also control -- will not be confusing.