5 ms·
I struggle to see how you pick Java over Kotlin on the JVM these days. It's everything that Java is, minus everything Java shouldn't be, plus everything that J
by rcaught 7y ago
I struggle to see how you pick Java over Kotlin on the JVM these days. It's everything that Java is, minus everything Java shouldn't be, plus everything that Java should be.
- jrs95 7y agoIt's the lowest common denominator. It's the same reason I haven't been able to adopt Kotlin at work. Everyone acknowledges it would be better, but "everyone knows Java". Seems almost like "nobody ever got fired for buying IBM" to me.
- cutler 7y ago... or, worse, "everyone here uses Java <= 8".
- ivan_gammel 7y agoSyntactic sugar does not solve programming problems. Kotlin does not offer any paradigm changes which could make switch worth it.
- deleted 7y ago[deleted]
- vbezhenar 7y agoThe only Kotlin feature that it's really hard to live without is properties. Otherwise sure, it's better than Java 11, but I can live without all those niceties. And (non)nullable types even get in my way! I just don't understand where there's syntax sugar for propeties in Java. There are lot of unneeded stuff added, that I don't really care about. But my classes are still full of autogenerated getters/setters. I recently tried to find some JEP and I did not find one. There was some talk around Java 7, but nothing since that. Nobody even wants to add properties support for Java?
- sverhagen 7y agoAnd (non)nullable types even get in my way! Interesting how that goes...: the sibling comment to yours said the exact opposite. How does this feature get in your way?
- vbezhenar 7y ago1. Language problem: if (this.prop != null) { this.prop.something() // does not work } this construction works for local variables, but not for properties. Yeah, theoretically it could be modified by another thread or function in the middle. In practice it does not happen and I'm forced to use terrible code like this.prop?.apply { prop -> prop.something() } (this example could be written as this.prop?.something() but that's not the point, usually it's harder than that. 2. Interoperation problem. A lot of Java code does not use @Nullable annotations, so all types are just that: platform types. So Kotlin nullability adds nothing to that.
- oweiler 7y agoProbably because in general they are a code smell. They are anti-OO.
- rcaught 7y agoKotlin's null safety alone is enough to prove you wrong here.
- maltalex 7y agoI find the whole discussion about null safety completely negligible. Since when are nulls the biggest problem for developers? Null pointer exceptions are by far some the simplest problems to avoid and/or solve. There are more serious arguments that can be made in favor of Kotlin.
- rcaught 7y agoWhere was it suggested that nulls are the biggest problem for developers? But they are a problem that happens, and in Kotlin, the compiler checks your nullable logic for you; instead of your users finding the errors at runtime.
- ivan_gammel 7y agoIt just a way to conceal bad coding practices, which doesn’t prevent from having the same problem in a different form, just like GC in JVM cannot protect from all memory leaks. I can hardly remember a case when NPE was reported by some user in my projects.
- aflag 7y agoIt was suggested that that feature is relevant enough to justify using kotlin over Java. However, I'd (and others in this very thread also have) argue that only slightly tips the scales towards Kotlin, while not solving the problem they were actually trying to solve here: reduce the barrier for contributing.
- JBiserkov 7y agohttps://duckduckgo.com/?q=billion+dollar+mistake https://duckduckgo.com/?q=billion+dollar+mistake
- wellpast 7y ago
- jackpeterfletch 7y agoCorrect null handling genuinely helps you write better, more correct, less bugged code. It's not just syntax sugar.
- pjmlp 7y agoInstal PMD and you are set.
- tanilama 7y agoExcept there is no need to do. They already biased for maturity and long term maintainability. I don't think Kotlin is bad per say, but it feels untterly unnecessary.
- p2detar 7y agoAs someone that uses both languages, I can't help but think that the OpenJDK will (hopefully) start implementing much of the Kotlin paradigms. Perhaps at some point Java & Kotlin would not differ too much. Let's see what the 6-month release cycle brings. That remains to be seen.
- pjmlp 7y agoI guess you mean Java here, and yes some of them have a JEP defined.
- fulafel 7y agoThey want to use a language that has a large pool of interchangeable "x years of experience in language y" labour available.
- pjmlp 7y agoBecause until JVM turns into KVM, Kotlin is just another guest language on the JVM, without much to add as a company pushing their agenda and trying to use the JVM as a lever. KVM might well turn out to be ART, but that is the extent of it.
- rnikander 7y agoAs someone who just started using Kotlin again, I'm curious what you mean by "agenda". A typical company trying to make products for money, or something else?
- pjmlp 7y agoYes, Kotlin as gateway drug into JetBrains products. For example, the graphical debugger for Kotlin/Native is only available in Clion. There is even a statement in that regard.