5 ms·
Modern Java is actually quite good. The main three things that Kotlin offers, in my eyes, are Data classes (in preview in JDK 14), Coroutines (should be coming
by vips7L 7y ago
Modern Java is actually quite good. The main three things that Kotlin offers, in my eyes, are Data classes (in preview in JDK 14), Coroutines (should be coming soonish with loom), and nullable reference types (not big enough for me to switch).
Outside of Android I wouldn't choose Kotlin.
- watt 7y agoNull safety is the one big win for Kotlin. https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html
- vips7L 7y agoI agree, but like I said it's not enough for me to switch. I use Optional<T> whenever I need to return null. The only outlier there is the JDK which most devs should know when it's returning null to you.
- dajohnson89 7y agoisn’t optional just replacing the null check with if(optionalRef.isPresent)?? i kinda get how this is safer, but clients can just call optionalRef.get() without checking, and boom there goes the safety. compiler warnings be damned.
- vips7L 7y agoOptional is just signaling to the user that they should check. You could also do this in Kotlin and boom there goes the safety: fn nonNull(): String { val s: String? = null return !!s }
- lllr_finger 7y agoI would tout sealed classes as well, although I think Java has a proposal that's getting traction. For back-end service/API type things in an enterprise setting, Kotlin is a good value proposition. There's also probably some truth to the idea that one reason modern Java is adding these things is because of Kotlin's existence.
- gambler 7y ago>Modern Java is actually quite good. Lambdas can't handle checked exceptions, which are the most common exceptions in the system. There is no way to extend Stream with your own methods. Still 8 primitive types to wrestle with. Just to name a few issues. And there are lots and lots more. The language is simply not extensible enough to write anything elegantly.
- vips7L 7y agoJust handle your catched exceptions? It's not that hard. () -> { try { // do work } catch (IOException ex) { throw new UncheckedIOException(ex); } } I also agree with Goetz that extension functions aren't something we need.
- pjmlp 7y agoNot only isn't hard, one can write a generic utility method. Regarding extension methods, while they are nice, with import static it just a matter where the extended type comes, big deal. And from experience in .NET world, hunting them down isn't always fun, even if they are just Ctrl+F12 away.
- deleted 7y ago[deleted]
- int_19h 7y agoWhat's the point of even having checked exceptions, if you're going to have an unchecked counterpart for every one of them just so that you can flow them through lambdas?
- cryptos 7y agoIt is not hard but cumbersome, ugly and ruins readability when used a lot.
- turk73 7y agoYou have incorrect information. It is not any more difficult to do any of the things you always did with Java using lambdas and functional programming concepts, you just need to learn how. You don't "extend stream with your own methods" you pass functions as arguments. You are thinking OO, stop thinking OO.
- wrmsr 7y agoI've found Optional<> to at least ~help~ with the null issue - as we still don't have value types it still does come with a runtime penalty but most of the code I write and deal with these days has a no-null policy: if it's optional it's Optional<>, everything else defaults to sane defaults or 'empty' (usually immutable) objects. There will of course always be nulls in legacy and performance sensitive code but it is at least ~something~.