Hacker News new | ask | show | jobs
by cel1ne 3387 days ago
Kotlin has generics that are in most circumstances reified enough ;).

Optionals of Java8 and Guava are a terrible idea. @Nullable is just an annotation. Null-safety built in the language is the only way to go.

You could always argue that a language is just cleaner syntax. Kotlin is a cleaner syntax for interacting with JVM-bytecode. Scala is a also cleaner syntax for interacting with JVM-bytecode. JVM-Bytecode is a cleaner syntax for interacting with operating systems.
2 comments
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.

link
cel1ne 3386 days ago
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.

link
lmm 3386 days ago
> 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.

link
pkolaczk 3387 days ago
> Kotlin has generics that are in most circumstances reified enough ;).

They are not more reified than what you can achieve by just putting Class<T> fields in Java objects to represent the runtime type of the generic type parameter. Sure, Java solution is kinda more verbose and ugly, but this is basically what people already said here: Kotlin has some nice syntax sugar.

But you still can't have two different methods differing only with the generic type parameter (e.g. List<String> and List<Integer>). And the code is still not-specialized properly, read "slow".

Real reification will be possible if project Valhalla arrives (maybe Java 10, who knows?)

link