Kotlin: The Problem with null

The Chris Lattner quote at the end explains the fundamental difference. Kotlin is an interloper in a Java world - that includes the JVM, a VM designed to run Java.

Swift integrates and interoperates with but is not based on the Objective C runtime. Apple also controls all the relevant bits and pieces and they can bridge, compile-to, shim, wrap, etc however they want. They can can pick the design approach and fiddle with all the parts to make them fit. This isn't a luxury Kotlin has.

> [Kotlin] does not overlay Java like e.g. Groovy does

Apache Groovy 1.x was dynamically typed only, and focused on scripting and glue code for the JVM and syntactic compat with java, so could be said to "overlay Java". Since Groovy 2.0 however, it changed tack with static typing targeted for Android development, not keeping up with syntax changes in Java such as lambdas from Java 8, and tried to compete with Java instead of complementing it. It no longer "overlays Java", and in fact lost out to Kotlin and Scala in its effort to compete with Java. Groovy should have stuck to its knitting instead of changing direction every few years.

> Instead you just get a crash if it is null which is worse in my opinion

Only in the same instances you would in Java-to-Java. So the ergonomics aren't improved or reduced. And really, this only helps on returns anyways. Marking every Java param nullable gets you nothing if the implementer didn't handle it well.

> This already happens automatically for parameters to a Kotlin function; check out the Kotlin Intrinsics checks.

Yup, and I don't like it. So even public Kotlin-to-Kotlin calls suffer. Haven't checked in a while, but I would like an option to use annotations only and skip those top-of-method checks.

ad 1: `!` in kotlin actually mean "platform type that could be nullable or not". When you add !! to a value of that type, you declare it as non-nullable.

For doubles you don't even need to take over NaN. There is a huge range of unused bit patterns in IEEE floats that could be used instead.

Just curious, if Some(hello).toString produces `hello`, what does None.toString() and Some(None).toString() and Some(Some(None)).toString() produce? (My guess is `None` for all)

I think it's impressive† that you got nesting to work, I'm really curious how you pulled that off for longs and doubles without incurring extra overhead.

† Though, given the magic you worked in getting Union types working in the ScalaJS facades I shouldn't be surprised.

It's no longer monadic in the presence of a pervasive `null` value. Such is the power of null - it breaks abstractions that have nothing to do with it.

In languages like Haskell and Scala that supports `do` / `for` comprehension sugar, this could be done without the nesting:

  fn :: Maybe Int -> Maybe Int -> Int
  fn q z = fromMaybe 0 $
    do 
      q_in <- q
      z_in <- z
      return (q_in + z_in)

In Scala, you can use `for`, although I think your point remains valid for languages without any sort of monad support:

    def func1(q: Option[Int], z: Option[Int]): Int = {
        (for {
            qval <- q
            zval <- z
        } yield q + z).getOrElse(0)
    }

In Rust you can also write:

    if let (Some(q_in), Some(z_in)) = (q, z) {
        q_in + z_in
    } else {
        0
    }

Most languages with monads have tools for working with them. In Haskell, for example, even without `liftM2` or `sequenceM`, you can simply do

    case (xm, ym) of
        (Just x, Just y) -> x + y
        _ -> 0

I know you have got a TON of replies demonstrating better ways to check if a value is null or not. I believe they are all missing the point. In a language with monads, Option's should not be part of the function signature unless it is important to the logic of that function. Your given example should look like:

    func1(a: i32, z: i32) -> i32 {
        return a + z
    }

I know it's not 1 to 1, but the idea is there. You would then use a tiny bit of glue code to combine all the stuff you have to get what you want. For example, if you have 2 nullabes as parameters, you use liftM2; if you have 1 nullable, you use liftM; or perhaps you just want reduce a structure, so you reach for foldM. etc. If your monadic code has to constantly figure out what monad it is, you aren't buying yourself much and I could see why you don't find them valuable. And if the function explicitly needs an Option, then it must be important and must be taken into consideration by the caller. I just don't think they should force the caller to consider them where not needed.

I wanted to mention I often see similar statements with almost the identical code comparison that you made. I believe it has to do with retraining oneself to think functionally instead of imperatively. I'm curious about your background.

For good measure, here's another example in Haskell:

    func1 a b = fromMaybe 0 (liftM2 (+) a b)

And an uglier, but fun, point-free version:

    func1 = (fromMaybe 0 .) . liftM2 (+)

I believe real-world examples would hold up better because the glue code would only be where needed.

As those others wrote you would probably use for

I wrote a little bit about how to work with the Future Monad in "A Little Guide on Using Futures for Web Developers'

http://codemonkeyism.com/a-little-guide-on-using-futures-for...

It doesn't sound like the OP is claiming that at all, Coverity and tools like it use a technique called Symbolic Execution [0]

[0]. https://en.wikipedia.org/wiki/Symbolic_execution

Uh, no? Null pointers are far from the halting problem, though.

And to be clear, there are still limitations. It can't say if any value you pass into a function that is not part of the current compilation is safe. For somewhat obvious reasons.

But for a large large class of bugs, using advanced tooling can go a long way. As evidenced by the power of the advanced tooling new languages bring into the compilers. :)

Only the experimental Coverity Hypercomputing branch ;-)

I think you may be conflating the Halting Problem. The problem simply states whether it can be determined that a program, given a set of inputs, will eventually halt. Attempting to use a null pointer can be deterministic at compile time but it's not telling you that your program would halt or not.

While the halting problem can be pretty important in some cases, it's not very relevant in most day to day code. If you're not sure if your code will ever terminate, that usually means that you're doing something wrong.

So sure, sometimes Coverity will fail because of the halting problem, and in those cases it can give an appropriate error message. Most of the time, though, it'll work just fine and be a very useful tool.

Ah, please don't take my point as dismissing the new tools, either. Indeed, I would hope that a synergy between all tools lead to better tools for us all. I just have a pet peeve for the attitude of jumping rather quickly to "rewrite it all in new language" and not realizing you can bring a lot of this into existing codebases.

Optional is a special case of a sum type where one of the types is Null. If you have Null as a type whose only value is null, then an Optional is just a T|Null. No need for Optional to exist.

Yes, that is what I meant, yes.

The author introduces his example with "Let’s take a look at a very short Kotlin + RxJava sample." But IMHO his sample describes a Java-only problem (and solution). He could have written a quite similar article without any mentioning of kotlin.

Remove part of your sentence, and I think you've answered your own question.

> How do you know it's "the problem"? [...] because this is a Java interop call.

If you're making platform calls, you know you have to deal with nulls (or at least, you should, in my opinion). So you declare returns nullable and avoid passing nulls unless that's documented to be okay.

Kotlin's Elvis operator makes this really easy:

val a: String? = null val b: String = a ?: "alternative"

I understand that. I still think the example isn't well chosen.

Whatever.

Dunno, but I'd have thought that you can make None look like a null pointer, but Some(p) needs to be tagged in some way.

Nulls can be nested if you are using a language with explicit pointer types.

E.g.,

  Int*** x;

Can be a lot like

  Maybe Maybe Maybe Int

It's just that in languages where a type like Integer really means “an integer or a null", the nullability doesn't nest, and no one wants to deal with naked pointers.