3 ms·

My takes is that Option is (next to) useless - the most common pattern is ...orElseNull() - yikes. The only sane approach is removing all nulls as early as the

• setr 5y ago
  The problem I think is that if your dependent apis aren’t also consuming Optionals, and relying on type = null || type logic, then you end up constantly translating back and forth between the two endlessly, defeating any ergonomic gains. The ideal state is that anything that isn’t Optional is guaranteed to be non-null. So when you go ahead and remove all nulls as early as possible, you can statically guarantee that remains true forever-more. But if all your libraries just go ahead and drop this knowledge anyways, and when they return an object without meaning non-nullable, then you’re back to where you started. Whereas in an ML, I know every library is already adhering to this, so something being not-optional actually means something. Bolting it into a language ad-hoc, you go from everything can be null to this weird tristate — a type might be nullable, or might not be nullable and if it’s in an optional, it definitely is nullable… so your best bet is just checking for null every time anyways