Indeed, dynamically typed languages tend to be worse about this. The concept is certainly useful in dynamically typed languages, and is easy to implement, but few have it in the "standard" libraries. One of the reasons is that some of the benefits are lost in a dynamically typed language. In a statically typed language, use of an
Optional type will force me to handle the "nothing" case, not so in a dynamically typed language.
Another aspect that's a double whammy is the relative commonness of the notion of "truthy" values. On the one hand, it makes it significantly easier to silently get the wrong behavior when using something like
Optional. On the other hand, certain patterns that
Optional can handle nicely can be accomplished by using truthiness, e.g. the ubiquitous
var x = passedInValue || defaultValue;
Still, it's not hard to imagine how the above could go wrong. "What if
false? Or what if I want it to be
undefined could (seemingly) serve some of these roles, but it's a "solution" that's worse than the disease and also not a solution.
The situation is very much like
null in most languages or
NULL in SQL. Truthiness amplifies the problems of
null. It may come as no surprise at this point that most statically typed functional languages lack an equivalent to
null. For some reason, after decades of existence, I'm not aware of any statically typed functional language that decided to add something like
null after the creation of the language.
Optional wouldn't have been useful in Java a decade ago.