5 ms·
In my eyes, the question is always why Kotlin? I don't think it offers much over modern Java. Maybe data classes? That's not a game changer to me. Coroutines?
by vips7L 6y ago
In my eyes, the question is always why Kotlin? I don't think it offers much over modern Java.
Maybe data classes? That's not a game changer to me.
Coroutines? Loom will be better.
Nullable references? This might be worth it, but in my experience Optional<T> is enough.
- nitrogen 6y agoIMO it's mostly syntactic convenience and elimination of boilerplate. The Kotlin collections APIs are more convenient than the streams APIs. Data classes are convenient. Nullability is significantly more convenient than Optional. And you get all that even if you have to target old JVM versions for some reason.
- rhencke 6y agoGroovy-like DSLs with compile-time checking and strong typing (and now @DslMarker is a nice bonus) are very nice. Check out inline functions and reified generics, too. There's some compelling stuff there.
- freeone3000 6y agoOptional<T> is itself a reference and can itself be null. That effectively torpedos the entire concept out of the gate. Nullity being part of the data type is a huge difference, and exposes so many "I didn't know that could be null" spaces.
- vips7L 6y agoI just see that as a non-argument. No one in their right mind returns null instead of Optional.empty() and I've never seen it done in the wild. Regardless in kotlin you can simply do: val s: String? = null return s as String or val s: String? = null !!s.trim() and lose all safety around nullability. Both hinge on a rogue developer not following best practices.
- The_Colonel 6y agoI've seen both Optional<?> return null (inexperienced dev) and somebody arguing we should defensively check for null Optionals as well (experienced dev). What you're arguing is a false equivalence. In practice null safety isn't a problem when developing in Kotlin while it is a big problem in Java.
- pjmlp 6y agoValhalla will change that, all value like classes are going to be value types in post Valhalla.
- eonwe 6y agoYes, that will happen eventually. Valhalla has now been coming since 2014, so I would not expect it to help any software project in the next two years or so.
- pjmlp 6y agoJava isn't Python, so great thought is being given to keeping those 25 year old jars running on an Valhalla world. Experimental builds are available.
- scns 6y agoYes, but all these features that are coming to Java in the future are worthless when you want/need to write software now.
- pjmlp 6y agoExperimental builds are available. And when they become available, Java will have them on day one, while Kotlin who knows, specially when it needs to stay compatible with ART. Kotlin designers will have eventually to face the reality that they are either an Android only language, or that Kotlin multi-platform will need to differentiate between what is supported on JVM and ART.
- The_Colonel 6y agoBut value types are not drop in replacement for reference types, i.e. you will still have null safety issues in a lot of cases.
- pjmlp 6y agoDepends if one makes use of PMD or not. Surely using nullable annotations is more typing than ! or ?, but that is about it, no need to change languages.