[NwpierratorR]

While philosophy is good, Java makes a very questionable syntactic choices when adopts that said features.

Pure slowness in how java develop feels like you have to wait 5 years to get something that other languages have, only to get it in the most aesthetically unpleasant way.

It seems like devs add unnecessary verbosity whenever they can.

Java adopted lambdas after many other languages, yet still decided that allowing to move last parameter closure {} outside of () is too radical, even though it is much more visually pleasant choice and quite common in other languages.

default methods in interfaces instead of static extensions. This one is controversial as static extension methods were not really common when java came up with this, but end result does not look impressive.

Same with their new sealed classes. They just chose the most verbose version they came up with.

Some inconsistency of choices also kinda baffles me. First they added support for skipping necessity of mentioning generic type inside <> during instantiation, only to introduce local vars later that require you to mention generic types within the same <>. Now you either mention generics by their full type always, or embrace the inconsistency and have it skipped when type mentioned in prefix and type it when using local vars. Or do not use local vars and have consistent codestyle with increased verbosity.

Java is still a good language, but it feels dated in syntax. TBH I have no idea why would anyone chose java in 2023 when there's kotlin, which not only fully covers the same functionality(okay, no pattern matching and no loom/valhalla until java merges it), but does it while being much more concise and readable.

[marginalia_nu]

I'd choose Java over Kotlin in 2023, in fact I'd do so most years. I'll pretty much take conservative language design over developer comfort every day of the week.

[Alupis]

But you do not have to choose Java over Kotlin - you can use them both in the same project without any side effects.

This was by design for Kotlin, and is probably their smartest/best feature. All existing Java code/libs just work in Kotlin. Conversely, most Kotlin code/libs just work in Java, although some care needs to be made there.

Kotlin is amazing to use and read. For most things, the Kotlin version is easier to read and comprehend than the Java version in my experience.

As Java adds language features, Kotlin either gets them for free or already had them (and now can use native features instead of their own custom features).

[pron]

Programmers rarely have consensus on anything language-related, but their preferences are not always evenly distributed. Our decisions re Java aim to cater for the majority of professional teams, which may not necessarily be represented by the majority of commenters on HN. If you don't understand why many more teams prefer a language with choices that appeal to you less over languages with choices that appeal to you more, the answer may be that your preferences are not the same as those of the majority of teams.

[skitter]

This is the most infuriating kind of answer: There are concrete complaints and this comment addresses none of them. Claiming that there are people who prefer Java's syntax to be inconsistent isn't useful without saying why they do.

[VagueMag]

> Some inconsistency of choices also kinda baffles me. First they added support for skipping necessity of mentioning generic type inside <> during instantiation, only to introduce local vars later that require you to mention generic types within the same <>.

I just came across this as a potential footgun the other day. I had a var list = new ArrayList<>(), then later added a bunch of Foo's into the list, and then when I called an overloaded method with the signatures log(Object obj) and log(List<Foo> fooList), it was calling the Object version. I would think some better type inference should be possible there, but if not, making programmers declare the type(s) at least once is a necessary constraint.

[kaba0]

Why don’t just write var list = new ArrayList<Foo>()? The point of inference inside <> has always been to save you from repeating yourself from copying from the left to the right, which is a non-issue when you are saved from specifying it on the left.