Earlier quoted context omitted.
Your comment kind of galvanizes my view that most of us suffer from Stockholm Syndrome with respect to our programming languages. As another commenter said, some statically typed languages give you unsigned numbers. Maybe most of them do. But definitely not some of the most popular ones. And out of the ones that do, they are often really unhelpful. C's unsigned numbers and implicit conversions are full of foot-guns.…
> We don't even need empty strings (or collections, really) if we have null. This feels exactly backwards to me: I almost always want my sequence-like types to have a well-defined zero-length element, and I almost never want to allow a NULL value for a variable. NULL is so much worse than [] or ''. Think about concat(). When the trivial members of a type support most of the same behaviors as the nontrivial ones, that…
I'm just exasperated that most of these modern, statically typed languages, give us TWO ways to write "nothing" (null and empty) and ZERO ways to write "must have something".
You COULD, theoretically, write a concat() that takes multiple, nullable, non-empty strings and returns a nullable non-empty string. Of course that's not ideal and would be horribly unergonomic. But you COULD do it. But how do you write a concat() that statically guarantees that if any of its arguments are non-empty that its output will be non-empty? You pretty much don't.