7 ms·

Yes, option types are awesome. No, they are not nulls. Algebraic data types are not direct support "no data found at the type level". Algebraic types are reall

• SpicyLemonZest 8y ago
  They’re not direct support, but option types only work in languages with the right syntax and tooling to make them work. C union types, for example, aren’t really capable of providing a null replacement simply because they’re so complex to use.
  • HumanDrivenDev 8y ago
    They’re not direct support, but option types only work in languages with the right syntax and tooling to make them work. I strongly disagree. You don't need pattern matching syntax to use option types effectively. All you need are the right methods - map, flatMap, getOrElse etc etc. Any language with inheritance and dynamic dispatch can implement a good option type. Even in languages with pattern matching, I never reach for it when dealing with options.
• dtech 8y ago
  Take a look at Kotlin or Typescript†. Basically, they decided to fully design the language with support for null-as-option. That means several things: * T (non-nullable) and T? (nullable) are different types. T? = T | null * Where T is expected T? is not accepted, but where T? is specified T is also accepted * T? is automatically cast to T in the places where it's asserted to be not null, e.g. within an if(x != null) branch * Method calls are not allowed on T? (unless the function specifies it can handle null) * There's syntax for providing a value in case of null. (x ?: fallback) in Kotlin, (x || fallback) in Typescript. It's a much more pleasant developer experience than the Option ADTs/Enum types from Scala or Haskell, which the same amount of safety. Typescript goes even further and has the best enumeration support I've seen any language have. T | U is a fully valid type, and if T | U is asserted to be one of them it is automatically cast to T/U. It is a very natural and efficient way of building ADTs [1] † Typescript 2.0+ with --strictNullCheck on [1] https://www.typescriptlang.org/docs/handbook/advanced-types.html https://www.typescriptlang.org/docs/handbook/advanced-types.... , Discriminated Unions header
  • davemp 8y ago
    These are great features, but they are really just syntactic sugar over algebraic types. It's not a more pleasant developer experience than sum (Option) types, it's a more pleasant experience with sum types. Ex: macro! unwrap(x, fallback) { match x { Some(n) => n, None => fallback }; } > Typescript goes even further and has the best enumeration support I've seen any language have. T | U is a fully valid type, and if T | U is asserted to be one of them it is automatically cast to T/U. It is a very natural and efficient way of building ADTs That's pretty cool. It seems like refinement types. [1] [1]: https://en.wikipedia.org/wiki/Refinement_(computing)#Refinement_types https://en.wikipedia.org/wiki/Refinement_(computing)#Refinem...
    • nostrademons 8y ago
      It's subtly different because of the implicit coercions and smart casts. You can always pass T to a function that takes T?, while in Haskell/Rust you would need to pass Some(t). Similarly, Kotlin does control-flow analysis and converts all T?s inside an "if (t != null) ..." block or after an "if (t == null) return" statement into a T, which dramatically reduces the amount of try!/unwrap() calls that I used to see littering early Rust code. There's better syntactic sugar for it in Rust now, but the point is that Kotlin doesn't need nearly as much syntactic sugar because nullable is integrated with the typechecker and flow analysis.
    • dtech 8y ago
      > It's not a more pleasant developer experience than sum (Option) types, it's a more pleasant experience with sum types. Having worked with both Scala, Haskel, Kotlin and Typescript I disagree, the dev experience for Kotlin/Typescript is miles ahead for optionality. It seems like a small difference vs something like do notation or for comphrehension but it really adds up. It hard to explain until you've tried it. The most succinct way would be to say that optional code looks and feels nearly identical to non-optional code, instead of unwrap/do-notation which makes a very large syntactical difference. Take a look at a piece of async Kotlin co-routine code v.s. Java/Scala (Completable)Future, same effect.
  • lmm 8y ago
• dragonwriter 8y ago
  > Yes, option types are awesome. No, they are not nulls. No, but they serve a superset of the semantic functions of nulls, better than nulls do.