6 ms·

- if you don’t use null this isn’t an issue - it’s verbose because handling optional values safely is complex

• Zababa 5y ago
  How is "handling optional values safely" complex? Do you have any examples of that?
• hn_throwaway_99 5y ago
  > if you don’t use null this isn’t an issue I mean, no shit. But the problem is that tons of existing Java APIs do use nulls, so you can't just pretend they don't exist, and importantly a major point of the optional construct is to get compile-time guarantees, and the Optional class doesn't give you that. > it’s verbose because handling optional values safely is complex No, it's not. Kotlin has optionals built into the language, and it's safer and much less verbose.
  • tadfisher 5y ago
    Nit: Kotlin doesn't exactly have optionals, it has essentially a type modifier (?) that represents a "nullable" type, i.e. the sum of a type T and the value 'null'. This is indeed safer and terser, therefore strictly more powerful than Java's Optional type, but it begs a question: Why not allow users to create similar higher-kinded types instead of baking this one very specific type kind into the compiler? Their recent decision to axe typeclasses in favor of multiple function receivers, which solves a small subset of problems that HKTs do in Scala and Haskell, make me look for greener pastures whenever I need them.