4 ms·

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 hav

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 4y ago
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 4y ago
  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).
  - krzyk 4y ago
    In my case Kotlin was harder to read than Java, so it really depends on the person. (Same thing with Groovy, but that one is even worse than Kotlin) On the other hand Scala looks nice.
  - pjmlp 4y ago
    Kotlin adds Jetbrains only as IDE, additional build plugins, an ecosystem of Kotlin libraries for more idiomatic code, stack traces completly unrelated to Kotlin as JVM only understands Java, and it needs plenty of boilerplate to emulate co-routines and functions in JVM bytecodes. Other than Android, there are no reasons for additional complexity in development tooling.
    - Alupis 4y ago
      Most of your points are not really valid if you understand Kotlin. It's not different than understanding Java really... > Kotlin adds Jetbrains only as IDE Not true, you can use any IDE you want. Of course IntelliJ is the "blessed" IDE, but really, Kotlin is just a bunch of libs, any IDE will work. > additional build plugins I don't see why this would matter. Any non-trivial build is going to use a bunch of plugins. > an ecosystem of Kotlin libraries for more idiomatic code Which are optional. > stack traces completly unrelated to Kotlin as JVM only understands Java I don't know what you mean. The stack traces are from bytecode, which Kotlin compiles to just like Java. The stacks are identical... > needs plenty of boilerplate to emulate co-routines and functions in JVM bytecodes You do not write the boilerplate though. That's the difference. Of course all higher level languages with High Order functions are going to suffer this same issue. It's abstractions all the way down.. You probably already use Kotlin and don't even know it. The popular okHttp library from Square is Kotlin - but you'd never know that if you just used it in your Java project.
      - andrekandre 4y ago
        personally i think kotlin is fine, but when compared to modern java, i feel like i need to really see a quantum leap before i'd go all-in if i was running a business (to say nothing of the labor pool for kotlin vs java)
pron 4y ago
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 4y ago
  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.
  - pron 4y ago
    1. I don't agree the syntax is inconsistent at all. All Java type declarations are terminated with a `}`. Using a different terminator is inconsistent, and that's the thing that requires justification. For the time being, while records are still new, the justification of saving a single character was deemed insufficient. When it comes to inference, I also don't see an inconsistency. Inference infers types or type argument based on the available data. For example, in `var x = new ArrayList<>()` there is simply no information that can allow us to infer a type argument; on the other hand, if a method's return type is `List<String>`, `return new ArrayList<>()` can infer the argument. 2. Even if there were inconsistencies, and certainly when it comes the the concrete complaints, people not only disagree on what's a preferable feature (I, for one, strongly dislike extension methods -- and consider them an anti-feature with a negative overall contribution -- and much prefer default methods) but they also don't pick a language based on one feature or another but based on a gestalt of properties. The languages mentioned by the commenters make different tradeoffs that have significant downsides alongside their upsides (e.g. they don't match the evolution of the platform; they add implicitness that makes it harder for some to read code; they have a lot of features that need to be learned, each of which is pretty underpowered), and it seems that more people prefer the overall tradeoffs Java makes. BTW, languages also have important meta-features. For example, every language needs to adapt over time, and the question is how it does so. The three languages that have managed to successfully support large programs that can evolve over time, maintained by changing teams -- C, Java, and to a lesser extent C++ -- have shown they take evolution seriously. They maintain compatibility and choose their features carefully (well, C++ maybe less so). Kotlin has lots of features, but it already has more outdated large features than Java because it adds features to address a certain problem and then the platform addresses them in an altogether different way (data classes, async functions), and as a result it's showing its age quicker, too. Java has proven that it evolves well, and many think it evolves better than most other languages.
VagueMag 4y ago
> 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 4y ago
  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.
  - VagueMag 4y ago
    Completely agree, but it did surprise me a bit and I didn't find much when I googled around for "don't mix var and the diamond operator."

marginalia_nu 4y ago

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 4y ago
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).
- krzyk 4y ago
  In my case Kotlin was harder to read than Java, so it really depends on the person. (Same thing with Groovy, but that one is even worse than Kotlin) On the other hand Scala looks nice.
- pjmlp 4y ago
  Kotlin adds Jetbrains only as IDE, additional build plugins, an ecosystem of Kotlin libraries for more idiomatic code, stack traces completly unrelated to Kotlin as JVM only understands Java, and it needs plenty of boilerplate to emulate co-routines and functions in JVM bytecodes. Other than Android, there are no reasons for additional complexity in development tooling.
  - Alupis 4y ago
    Most of your points are not really valid if you understand Kotlin. It's not different than understanding Java really... > Kotlin adds Jetbrains only as IDE Not true, you can use any IDE you want. Of course IntelliJ is the "blessed" IDE, but really, Kotlin is just a bunch of libs, any IDE will work. > additional build plugins I don't see why this would matter. Any non-trivial build is going to use a bunch of plugins. > an ecosystem of Kotlin libraries for more idiomatic code Which are optional. > stack traces completly unrelated to Kotlin as JVM only understands Java I don't know what you mean. The stack traces are from bytecode, which Kotlin compiles to just like Java. The stacks are identical... > needs plenty of boilerplate to emulate co-routines and functions in JVM bytecodes You do not write the boilerplate though. That's the difference. Of course all higher level languages with High Order functions are going to suffer this same issue. It's abstractions all the way down.. You probably already use Kotlin and don't even know it. The popular okHttp library from Square is Kotlin - but you'd never know that if you just used it in your Java project.
    - andrekandre 4y ago
      personally i think kotlin is fine, but when compared to modern java, i feel like i need to really see a quantum leap before i'd go all-in if i was running a business (to say nothing of the labor pool for kotlin vs java)

pron 4y ago

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 4y ago
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.
- pron 4y ago
  1. I don't agree the syntax is inconsistent at all. All Java type declarations are terminated with a `}`. Using a different terminator is inconsistent, and that's the thing that requires justification. For the time being, while records are still new, the justification of saving a single character was deemed insufficient. When it comes to inference, I also don't see an inconsistency. Inference infers types or type argument based on the available data. For example, in `var x = new ArrayList<>()` there is simply no information that can allow us to infer a type argument; on the other hand, if a method's return type is `List<String>`, `return new ArrayList<>()` can infer the argument. 2. Even if there were inconsistencies, and certainly when it comes the the concrete complaints, people not only disagree on what's a preferable feature (I, for one, strongly dislike extension methods -- and consider them an anti-feature with a negative overall contribution -- and much prefer default methods) but they also don't pick a language based on one feature or another but based on a gestalt of properties. The languages mentioned by the commenters make different tradeoffs that have significant downsides alongside their upsides (e.g. they don't match the evolution of the platform; they add implicitness that makes it harder for some to read code; they have a lot of features that need to be learned, each of which is pretty underpowered), and it seems that more people prefer the overall tradeoffs Java makes. BTW, languages also have important meta-features. For example, every language needs to adapt over time, and the question is how it does so. The three languages that have managed to successfully support large programs that can evolve over time, maintained by changing teams -- C, Java, and to a lesser extent C++ -- have shown they take evolution seriously. They maintain compatibility and choose their features carefully (well, C++ maybe less so). Kotlin has lots of features, but it already has more outdated large features than Java because it adds features to address a certain problem and then the platform addresses them in an altogether different way (data classes, async functions), and as a result it's showing its age quicker, too. Java has proven that it evolves well, and many think it evolves better than most other languages.

VagueMag 4y ago

> 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 4y ago
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.
- VagueMag 4y ago
  Completely agree, but it did surprise me a bit and I didn't find much when I googled around for "don't mix var and the diamond operator."