I Clojure its like this: (first []) --> nil

What is in that list? Answer nothing.

I think thats a way to go too.

    first [nil] == first []

    user=> (= (first [nil]) (first []))
    true

If you have a list of Ints, then what can you do with nil returned? It's not an Int.

Nils have a habit of propagating through the whole type system, and you then need to have rules about how they apply to every function. (What is 1+nil? What is nil:[1,2,3]?).

Eventually every single function will either have odd behaviour when confronted with a nil, or will be a source of exceptions (which are generally undesirable in a pure functional setting).

Haskell encourages you to write patterns that check for these edge cases, and handle them explicitly:

foo [] = ...

foo (x:xs) = ...

I would agree that not having nil is better if you have these big typesystems but for a dynamic languge its hard to avoid.

Question: Don't these static langauge use "unit" to signal what nil would do in clojure (in some casses)?