Hacker News new | past | comments | ask | show | jobs | submit login

Nothing you just said is true. Optional doesn't add complexity, it makes complexity explicit. The rest is just Java implementing it poorly.



And because it is implemented poorly, it adds complexity. Even Scala, which had Option from start, has three ways to return value from Map (Option, nullable return value, and throw an exception if not found). Kotlin has only single way.


> (Option, nullable return value, and throw an exception if not found)

Which Map are you talking about? I don't see the method that returns nulls for missing values.

> Kotlin has only single way.

... with the nice side-effect of being unable to tell whether the key didn't exist or if it was null. That's the single worst approach one can take.


Java maps return null, sometimes I have to use those in Scala.

Most Java Collections does not allow null keys and null values.


So you blame Scala both for Java's mistakes as well as addressing them, while Kotlin, which doubles down on Java's poor decisions does everything right? This makes literally no sense at all.

Also, only a few of the newer concurrent Java collections disallow nulls. All the classes commonly used allow null, as well as the collection interfaces themself.

Java had the chance to address this with Optional, but they got the implementation of the null handling completely wrong. Now they are stuck with it, which caused an obscene amount of complexity in the new generics spec to work around it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: