New language features since Java 8 to 17

> Well for one, it has a repl

Jshell

> As per single core performance, javascript is faster and has had first-class-functions from the beginning

Doubt. And no matter how I count, Java had first class functions for 8 years now, at the very least. Does it really matter when exactly did a language feature got implemented?

> and you don't need 10 lines of code to print hello something to the screen.

jshell: System.out.println(“hello world”)

> and JavaScript(ES6) is actually multiparadigm.

That hardly means anything. There are entirely FP libs available for Java.

> I speculate that most users of languages that have these features (Kotlin has all of them) would be unhappy if you took them away.

Kotlin has very little impact over the ecosystem due to its small market share (compared to Java). Plus, it has no influence over the platform, or any of the other platforms it targets for that matter, with the possible exception of Android, although I guess that's up to Google. The best it can do on the Java platform is make current practices a little easier. Java, on the other hand, has the option of changing the platform and the ecosystem and moving it toward better practices.

> in other successful JVM languages

Just so that we're clear, for over a decade now, the portion of Java platform developers using all other "successful JVM languages" combined has been pretty much steady at 10%. That's not to say they're not popular in absolute terms, but Java is so stupendously popular, that it's in a completely different league.

> If these features are such bad ideas there should be plenty of stories of Kotlin/C# devs cursing the language for providing them with these footguns.

Those languages appeal to different people, and, in the case of Kotlin, at least, they're the best they can do given their clout. If I don't like something, there will be those who do. The question is, how many? When I said that the features are bad or superseded by better ones, I didn't mean they're necessarily bad for all people or all languages, just that they're either bad for Java or that Java can do better.

> has no reason to fear that Kotlin will lose steam

The way this works is that the alternative languages on the Java platform fight for market share with each other. Kotlin will not disappear because of Java, but it will eventually lose its market to some other alternative language, just as Scala has lost to Kotlin. 10% of people just prefer other languages, and I am very happy that the platform can accommodate them. We'll continue working to make sure that the platform is a good target for different languages that appeal to different people. Other languages don't take away from the Java language, but make the platform more appealing to people who prefer less mainstream languages, and so we all win. Java's 9/1 ratio of Java language vs. others is a pretty good one, and we're trying to preserve it (we would be even happier with 85/15 or 8/2, as it probably means a larger market share for the platform overall rather than a smaller market share for the language. Remember that OpenJDK is funded by people buying support; they're not buying support for the language, but for the platform). If the non-Java-language market has shifted from Groovy and Scala to Kotlin, as that's what most of those in that group prefer -- so be it (although I do wish more people use Clojure; it is, IMO, the most interesting and best design alternative Java platform language out there, and one of the most interesting and best designed languages around in general).

The strategy that keeps the VM is innovative and the language is conservative has worked very well for Java, and because it's expected to remain very popular for a couple of more decades at least, we are very careful about adding features. The goal is to avoid new features as much as possible, and the way to do that is to add fewer, but more powerful features.

But that verbosity doesn’t scale with code size, so it is largely meaningless.

OP meant the public static void main part (that is you define what happens encapsulated in a class) Of course implicit imports are needed, like what else would you have without?

Yeah of course it depends on your definition — and in case of such a widely used framework I would usually use type safe with regards to user code, but you are entirely right!

But another point I had in mind is regarding the JVM is that it is strongly typed so such an error will be at least visibly and fail with a proper error message.