Hacker News Reader

Comment by lmm | Hacker News Reader

> What do you want from them? They have no ability whatsoever to control this. Either get annotations in the Java code if you can modify it (which is a good idea anyways), or wrap it and provide nullability information.

What I want is consistency. In Scala optional is always safe and null is never safe, and that's true whether you're calling a Scala method or a Java method (even the most perverse Java libraries don't declare themselves as returning Optional<String> and then return null). In Kotlin null is safe some of the time and not safe other times, e.g. if you're passing it to a method it might be fine or might not.

View on HN

In Kotlin null is always safe. The problem is that types imported from Java are "platform types", i.e. Kotlin doesn't know whether they're nullable or non-nullable, and it's up to the programmer to check their API docs and insert the appropriate handling at the call site.

For example, in my own pure-Kotlin code, "val id: String" is a non-nullable type "String"; the compiler will guarantee that it is never null. "val url: URL?" is a nullable type "URL?"; the compiler checks for null, and I need to use ? or !! or a smart-cast to access it. HttpServletRequest.pathInfo is a platform type "String!", is marked as such in autocomplete, and could be either null or non-null based on the API; it's up to me to use it appropriately.

The difference between platform types and nullable types is that platform types can be silently coerced to non-null types, even though they may be null. This was an ergonomic decision; you use so many Java APIs in Kotlin that the language would be nearly unusable afterwards (kinda like how Scala, rather than being a "better Java", has developed its own ecosystem of idiomatic Scala code). It's a potential safety hole, but it's clearly documented; think of it like getting memory management right in a C FFI.

> In Kotlin null is always safe. The problem is that types imported from Java...

Well yeah. But Kotlin advocates say you're supposed to use those extensively.

> think of it like getting memory management right in a C FFI.

Yeah, that's pretty terrifying. I would never want to use a language that expected me to make extensive use of a C FFI. It was bad enough when I used Python, and that involved a lot less C than Kotlin does Java.

You would normally check null on language boundaries:

  val path: String = req.pathInfo ?: ""

Now path is a non-nullable String, and you can be sure that it will never contain null, and you have specified exactly what the behavior is if the Java API returned it.

> Yeah, that's pretty terrifying. I would never want to use a language that expected me to make extensive use of a C FFI. It was bad enough when I used Python, and that involved a lot less C than Kotlin does Java.

You do this every day, regardless of which language you use. Your POSIX APIs and OS services are all in C. That they generally work is because numerous people have invested the time into putting appropriate error checks & memory safety into the host language bindings.

It's the same story with Kotlin: when you write code that uses a language (Java) that doesn't have appropriate safety mechanisms, you read the docs & code carefully, and then you use the safety mechanisms that your language (Kotlin) gives you for all the code you write. There is really nothing Kotlin can do about this: the original code is written in a language that doesn't make the distinction between nullable and non-nullable, so there is no information in the type system about whether it should map to a nullable or non-nullable type.

> You do this every day, regardless of which language you use. Your POSIX APIs and OS services are all in C. That they generally work is because numerous people have invested the time into putting appropriate error checks & memory safety into the host language bindings.

Not when I'm working on ocaml unikernels, but sure. The point is I only use languages where those bindings already exist and are maintained; I wouldn't want to use a language that expected me to use a C FFI directly in day-to-day work. Whereas the Kotlin narrative is that you do use the Java "FFI" directly in day-to-day work.

I don't see a huge difference between Scala's Options and Kotlin's null safety. In Scala, you can still do this:

    val x: Option[Int] = null

In theory you can. But you'd know to immediately fail that line in code review (or better still, enforce it at build time via wartremover). Whereas in Kotlin

    someMethod(null)

might be perfectly legitimate or might not, but you can't tell without knowing the details of someMethod (whether it's a Java method or not).

Maybe I'm missing something but how is that different from Scala or Java?

That will fail at compile time in Kotlin if the method is written in Kotlin and has a non-nullable parameter. Even if it's Java I think it will fail at compile time if the Java parameter is annotated with @NotNull.

If it is a Java method and not annotated with @NotNull then of course it will be allowed at compile time because how could it possibly not be allowed? What are you saying is preferable in that case?

The trouble is in idiomatic Kotlin you have lines like that, because when you want to represent absence you use nullable parameters. So you can't assume a line like that is wrong. But you can't assume it's correct just because it compiled either, because as you say it might be an unannotated Java method.

In idiomatic Scala you would never have a line like that (because you represent absence with optionals rather than null). So you can insta-fail any line like that in code review (or give very careful review in the rare case that it's calling a Java method that accepts a nullable parameter, but good modern Java libraries are moving away from those, so that case should go away).

The main difference is that Kotlin can do both: nullable types or `Option` (and you'd never use `Option` unless you are dealing with it coming from Java, obviously).

Scala can only do `Option` since it doesn't have built in support for nullable types.

I fail to see how your point shows any superiority from Scala here, it's the other way around.

At the end of the day, both languages have nullability support but since it's optional in Scala (because library based), Kotlin's approach is superior in that it requires developers to deal with nullability, while Scala developers can ignore it any time they want.

Nullable types are worse than Option in every way that matters (yes they save a few bytes of memory occasionally, but who the hell cares, if you care about shaving 8 bytes off an object you won't be using the JVM in the first place. It's certainly not worth the cost of working with a weird, second-class type that you can't abstract over like other types). Why do you want an extra way of representing the same thing with more special cases?

> Kotlin's approach is superior in that it requires developers to deal with nullability

But it doesn't force them to deal with nullability when interacting with Java which is the only case where it matters.

Scala calling Scala: you never use null, you never hit a problem with null.

Scala calling Java: you have to manually check return values for older libraries but at least passing in null can't happen.

Kotlin calling Kotlin: you use null a lot, you never hit a problem with null.

Kotlin calling Java: you have to manually check return values for older libraries and won't notice where you're passing in null because that's a normal, safe thing to do when calling Kotlin.

I don't know why you keep coming back to the Java interop aspect:

- It's trivial to solve and really not a problem in practice. I'm pretty sure that when you think about and write code, it's 99% in Scala and very little about Java. "Oh, this value is coming from Java and therefore can be null, I'll wrap it in an Option. Done".

- Kotlin and Scala are exactly on the same level when it comes to interoperating with Java. And I bet we solve it the same way: catch the nullable values from Java as soon as possible before they enter the Scala/Kotlin world, and now we're safe again.

The more interesting case for me is pure Scala or pure Kotlin. And I very much prefer Kotlin's approach to nullability for all the reasons I've enumerated, but let's not go over this again.

> - It's trivial to solve and really not a problem in practice. I'm pretty sure that when you think about and write code, it's 99% in Scala and very little about Java. "Oh, this value is coming from Java and therefore can be null, I'll wrap it in an Option. Done".

That works for values coming out of Java but not for values going into Java.

Isn't pure Kotlin a much more unlikely scenario than pure Scala? Kotlin devs certainly take pride at every opportunity of how much Kotlin piggybacks on Java, cf. collections.

I think you can't have it both ways, having a worse abstraction for handling errors while claiming that it works better with Java code and then claiming that "pure Kotlin code" is where the more interesting case is.

No, JetBrains is actually working on Kotlin Native [1].

[1] https://kotlinlang.slack.com/messages/kotlin-native/

Yes, exactly, which makes the claim even more baffling.

Sure, they can just reimplement all their Java dependencies, but if they have to implement e.g. collections anyway, they could just have designed a better API in the first place, instead of being stuck with Java collections on platforms that don't even run Java.

I think there's some misunderstanding about what goes on with an Option<T> type in the compiler. In a sane implementation of Option<T>, there's no space premium for using it over T. The compiler compiles Some<T> to a pointer to T, and it compiles None to null. Swift, Rust, and Haskell all do this; I don't know Scala that well, but I'd imagine it would too unless there's some edge case in Scala<->Java interop.

Kotlin's nullable types and Option are exactly the same thing, except with some implicit conversions and smart casts available (marked by the IDE). Using Kotlin & Rust syntax, I make the following mental equivalencies:

  T? <==> Option<T>
  maybeNull!! <==> maybeNull.unwrap()
  maybeNull ?: default <==> maybeNull.unwrap_or(default)
  maybeNull == null <==> maybeNull.isNone()
  maybeNull != null <==> maybeNull.isSome()
  maybeNull?.method() <==> maybeNull.map(|v| v.method())
  maybeNull?.method() ?: default <==> maybeNull.map_or(|v| v.method(), default)

The comparison is even more apparent if you're used to Swift, which has a separate Optional type but the same syntactic sugar as Kotlin for manipulating it.

The two ways that Kotlin nullable types differ from Options in other languages is that you have smart casts (if the compiler can prove that the value is never null, you can use it as a normal variable without explicitly unwrapping), and you have automatic coercions from platform types.

Also, I almost never use null in idiomatic Kotlin programming.

I think this comment shows a very fundamental lack of understanding how different languages handle errors.

In Java (and Kotlin) -- ignoring the topic of exceptions as an alternative -- errors like "missing value" are communicated with null.

So in Java you first have an error handling problem, you deal with it by returning null ... now you have a null handling problem!

Kotlin tries to put some band-aid around nulls by making them more typed than in Java.

In Scala, errors are handled with bog-standard library types like Option, Either, Try, Validation, not some special language built-in. These types are not facilities to handle null (shown by the fact that all these types happily accept null as a valid value), they are facilities to handle errors.

They handle errors better than Java or Kotlin, because these types allow developers to choose the appropriate type for a specific error case and retain the structure of a computation. To expand on the second point: Nullable types cannot be nested, Scala's types can and regularly are.

This allows Scala to compose operations while carrying errors up to the point where they can be handled easily.

If you have an operation returning an Option[T], and want to run an option on the value returning an Either[S, T] then simply looking at the resulting value will tell you if things succeeded or where exactly things went wrong.

    None               --> First operation did not result in a value
    Some(Left(fail))   --> Second operation failed with cause "fail"
    Some(Right(value)) --> All operations succeeded with result "value"

In Java and Kotlin all you would get would be a bare null, with a probability of people giving up on (typed) null completely and just throwing an (unchecked) exception instead.

TL;DR: Kotlin tries to put some band-aid around Java's broken approach of handling errors with null, Scala deals with errors correctly in the first place.

Outside of very specific low-level operations like Maps or taking .first() of an empty list, you don't handle errors with null in either Java or Kotlin. You handle them with exceptions. You can't ignore the topic of exceptions as an alternative - that is the idiomatic way to signal an error in Java and Kotlin. Nobody seriously considers having high-level APIs return "null" on error; for one, there's no way to differentiate the different things that can go wrong.

Now, there's an alternative school of thought that's gaining currency in languages like Rust, Go, and apparently Scala, and is how we used to handle them in C. That's to return special out-of-band values as part of the result type. The Either type in these languages (realistically, you wouldn't use an Option for any high-level API) in these languages makes this really easy, and sum types in general make pattern-matching on the specific error code & passing back diagnostic information a lot easier than it was in C.

I don't really want to get into a debate about error-by-value vs. error-by-exception, because there are good arguments on both sides of the debate and it's far from a settled question. Personally, if I were starting a new language today, I'd use return values for "expected" error conditions and some sort of panic/recover mechanism to indicate that the programmer forgot to handle a case.

But there's a really strong reason why Kotlin uses exceptions: interoperability with Java code. It's the same reason that Google bans exceptions in their C++ code: you can't really change the error handling mechanism of a large body of existing code, because the existing code's API all assumes certain language conventions, and if you break those conventions, you might as well rebuild the ecosystem from scratch.

So sure, if I were starting a language & ecosystem from the ground up, I'd probably use return values & pattern-matching. But I use Kotlin specifically because I want a "better Java", and need to integrate with Java libraries that may return null and will throw exceptions. If I didn't have those constraints, I'd use Rust instead.

Go uses multiple returns for this, IIRC, not an Either type.

I have seen plenty of libraries using null to indicate an error. If this wasn't the case, as you allege, then why do Kotlin devs act like it's such a big deal? Why add a language feature for something that isn't even considered an issue instead of e.g. improving how Kotlin handles checked exceptions?

One thing I find really frustrating is that Ceylon didn't take advantage of its union types to represent checked exceptions that way :(

Some(T) is not a pointer to a T in Rust. It's just a T.

If it were a pointer type, then yeah, it would be a pointer.

Presumably it has a different representation from a bare T? E.g. if T=Boolean then there are only two possible values for it, whereas there are three possible values for Option[T], so they need different kinds of storage (obv. in practice a boolean probably doesn't use a whole byte so you can do a kind of packed optimization, but you can't scale that arbitrarily far for deeply nested Option[Option[...Option[T]...], and this is an issue one would expect to hit with an integer or pointer where the natural representation is a full word that doesn't have any "spare" states).

Yes, there's an optimization. Specifically, there's a trait called "NonZero"; if T implements it, then Option<T> uses all zeros to represent None, and so std::mem::size_of::<Option<T>>() == std::mem::size_of::<T>(); If not, then you have to store a tag.

> Kotlin's nullable types and Option are exactly the same thing

I don't think that's accurate.

First of all, Scala's Option is a monad, no such thing with Kotlin's nullable type.

And second, Kotlin's nullability is enforced by the compiler so you can't escape it. In Scala, you are welcome to ignore nullable values whenever it pleases you (or when you forget to wrap them in an Option).

They solve a similar problem but with different approaches and different pros and cons.

> First of all, Scala's Option is a monad, no such thing with Kotlin's nullable type.

Is your point that Kotlin's type violates the monad laws? It does, but all that means is that certain constructs behave in really surprising ways and refactors that look obviously safe aren't. I don't see how that could ever be construed as an advantage.

If Kotlin's type conformed to the laws (which would be a great improvement) then it would be a monad even if you ignored that fact. All ignoring it means is that you don't get to take advantage of some common generic functions, but have to write them out separately every time instead.

> And second, Kotlin's nullability is enforced by the compiler so you can't escape it. In Scala, you are welcome to ignore nullable values whenever it pleases you (or when you forget to wrap them in an Option).

In Scala you're forced to check Options (or, better, handle both cases), so it's the same. Yes, if a "bare" null were somehow to get into your program then you would miss it. But where would that null come from? Only from a Java library and that's exactly the same problem in Kotlin. (Theoretically you could also get one coming out of some really bad Scala code, but the library ecosystem knows better than that, and in your own code you either simply don't do that or you use wartremover to enforce that you never do that)

> In Scala you're forced to check Options

But you're never forced to use them. That's the main problem with Scala's approach: it's entirely er... optional.

The Scala compiler will never tell you "You can't write a.foo() because a may be null".

> Only from a Java library and that's exactly the same problem in Kotlin

No, it's not. The Kotlin compiler will not let such values enter Kotlin code until you've told it precisely whether that type is nullable or not.

Scala has no such mechanism so null values can enter Scala code without the compiler having any say over it.

> But you're never forced to use them.

Use wartremover, then you are. Or just never write "null" (or check for it in code review). Yes ideally it just wouldn't be there, but it's really not hard to avoid it.

> The Scala compiler will never tell you "You can't write a.foo() because a may be null".

But you'll never get yourself into a position where a may be null (unless a came from a Java library, but that exact same problem can happen in exactly the same way in Kotlin). If you need to represent absence you'll use Option, and the compiler won't let you write a.foo() if a is an Option.

> No, it's not. The Kotlin compiler will not let such values enter Kotlin code until you've told it precisely whether that type is nullable or not.

No it doesn't. It lets you silently treat a type returned from a Java library as non-nullable.

> Use wartremover, then you are.

Well, yes, that's my point: that the Scala compiler can't do it, so you need an external tool to do it for you.

It's a similar argument to a dynamic language programmer saying their language is statically typed, you just need to use that external tool to type check it.

> But you'll never get yourself into a position where a may be null (unless a came from a Java library, but that exact same problem can happen in exactly the same way in Kotlin)

Again, no it can't.

Types coming from Java are marked as "platform types" by the Kotlin compiler and they are not allowed in the Kotlin code base. You need to convert them to a bona fide Kotlin type first (basically, decide if it's a nullable type or not).

It's the third time I've mentioned this and you keep ignoring it.

In contrast, Scala happily lets Java types enter the Scala object world, along with its null values.

> Well, yes, that's my point: that the Scala compiler can't do it, so you need an external tool to do it for you.

It's a compiler plugin so the compiler can do it, it just needs a little configuration. And in practice you don't need it.

> It's a similar argument to a dynamic language programmer saying their language is statically typed, you just need to use that external tool to type check it.

No it isn't, at all. The reason that doesn't work for dynamic languages is a) they tend to use inherently dynamic constructs that can't be safely typed b) the library ecosystem often isn't typed or is typed inaccurately. Neither of these things happens in Scala.

The ecosystem doesn't use null, no-one uses null in their code, it's a complete and utter non-problem. It's like the "haskell is no safer than anything else because you can still call unsafePerformIO" nonsense.

> Types coming from Java are marked as "platform types" by the Kotlin compiler and they are not allowed in the Kotlin code base. You need to convert them to a bona fide Kotlin type first (basically, decide if it's a nullable type or not).

Yes except they're implicitly convertible to non-nullable. So in practice it's no better than treating them as non-nullable.

> In a sane implementation of Option<T>, there's no space premium for using it over T. The compiler compiles Some<T> to a pointer to T, and it compiles None to null. Swift, Rust, and Haskell all do this; I don't know Scala that well, but I'd imagine it would too unless there's some edge case in Scala<->Java interop.

This is wrong for Scala, and I think it's wrong for the other cases.

> Kotlin's nullable types and Option are exactly the same thing

Except that it doesn't nest properly. Which means it's not compositional: if you write code that works with T?, it will have surprising behaviour if someone ever passes a nullable type for T. And you can't abstract over it, though that's a more general problem of Kotlin not having HKT.

> Also, I almost never use null in idiomatic Kotlin programming.

How do you represent optionality then? I use Option and None pretty often in idiomatic Scala programming (and when I don't it's usually because I'm using a richer variant on the same thing e.g. Either or a custom sum type appropriate to the business requirements) - there's a reason it's such a common example, it comes up in realistic problems all the time.

Why on earth would you ever want to do this? This is not how you use an Option.

That's not the point. The point is that any safety you think you have by using an Option is a little bit hand-wavy.

That's not _bad_, but the argument being made by the OP was that nullability in Kotlin was unsafe and inconsistent.

My argument is that while you use null assignment and nullability in Kotlin, in Scala you don't work with nulls.

If your entire code base is in Kotlin, then nullability works exactly like Options. The difference is sugar. And the Kotlin compiler can handle null checks as well as the Scala compiler handles Options.

The problems arise when you interop with Java. At that point, shit can be null and you just don't know. My point is that it's the same problem in Scala as it is in Kotlin: Java interop adds a measure of unpredictability that needs to be handled at the touch points.

I agree on all these points.

Reply on news.ycombinator.com