Hacker News new | ask | show | jobs
by lmm 3387 days ago
Optional is a concept that you need even in a null-safe language (e.g. Haskell has Maybe). With language-level nullability you can sort-of emulate a pseudo-Optional type, but why would you want to? It's inherently second-class because it can't ever be properly compositional (Option[A] is always a different type from A and can be understood without knowing anything about A, whereas A? might or might not be a different type from A, you can't understand what it does without knowing the details of what A is).

Once you start interacting with JVM bytecode Kotlin ceases to have null-safety. @Nullable is just an annotation but at least you can write it down, unlike Kotlin's "platform types". Conversely if you're not interacting with non-Scala bytecode then Scala is null-safe in practice if not in theory, because the Scala ecosystem doesn't use null and has tools to enforce this.

1 comments

I think it most real code you're better off without the Optional monad.

A variable being null is not a condition you can always a have a name for. You want to use it sometimes, but not built your entire vocabulary around it.

You also don't usually want to pass wrapped nulls around, you just want nulls available in local state.

> You want to use it sometimes, but not built your entire vocabulary around it.

Sure, which is why it should be an ordinary library type written in the language (and operated on with normal methods), not a magic special type with direct compiler support and custom operators.

> A variable being null is not a condition you can always a have a name for. You want to use it sometimes, but not built your entire vocabulary around it.

> You also don't usually want to pass wrapped nulls around, you just want nulls available in local state.

Why are you thinking in terms of "null" and "wrapping"? Think in terms of the business condition you want to represent. Often you have the possibility of some value being not-set or unknown in your data model - this comes up often enough that it's worth having a standard library type to represent it. "A variable being null" is not something that happens a priori, it's just an unfortunate representation certain languages adopt.