4 ms·
Kotlin's null safety alone is enough to prove you wrong here.
by rcaught 7y ago
Kotlin'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 agoHere here. I’ve heard “but null pointer errors!” countless times to justify one’s coding approaches (eg, strong typing, Maybe/Optional invasion, this or that PL, ...) People will murder all kinds of productivity to avoid potential NPEs, when as you say they are generally the easiest bugs in the world to contend with. It is beyond baffling to me, and given how often I hear it, it makes me question the dev world’s sanity.
- rmetzler 7y agoLately I’ve seen code bases where the Java devs don’t return empty arrays or collections but return null instead. Of course they have to test for null in their calling code. I suggested to return empty collections and objects implementing the NullObject pattern. I think this will make the code more readable, simpler and more secure, but I was answered with skepticism.
- wellpast 7y agoInterestingly I agree w/ a preference for empty semantics over null semantics, but NOT for the reason "avoid NPE". Rather, I think minimizing branching/forking in the code logic is how complexity is reduced. For this same reason I don't care for NullObject/Maybe/Optional type approaches which simply do not change the branching forking in your code: if (val == null) { ...logic... } This branching here ^ is not improved at all by a different syntactical representation: ((Optional) val).ifNull(v -> ...logic...) You are still branching, so in my opinion you've made no substantial improvement here. (I can already hear the "but, but..."s.
- p2detar 7y agoI'm dealing with an old code base in which methods tend to process exceptions by catching, logging and returning a null. The dev that wrote this code treated exceptions more like a rare-occurring annoyance rather than a signal for error, thus none of the calling methods had null check branching implemented. The amount of NPEs I had to fix in the past year is astounding. Optional to me is a large leap forward. That being said, I also don't like its verbosity and wish for it to be improved somehow.
- pjmlp 7y agoYou can easily get it on Java with PMD and other static checkers.
- mruts 7y agoIf you care about null safety, why not just use Scala? I've programmed Scala professionally for a long time and have never ever experienced a null pointer exception.