null-безопасное программирование

Несколько дней назад мне попалась ссылка, где известный корифей структурного программирования Хоар извиняется за изобретение пустой ссылки null: «I call it my billion-dollar mistake. It was the invention of the null reference in 1965 … More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.»
Это очень странно звучит, особенно если учесть, что в современной индустрии программирования наоборот стремятся добавить null к типам, в которых его никогда не было. Например, в C# используются так называемые nullable-типы, например:

int? i;

что означает, что i может хранить как целое число, так и null. Это удобно, в частности, для алгоритмов поиска, которые обычно возвращают −1, когда ничего не найдено, что приводит к появлению магических чисел в коде. Если возвращать null, читабельность программы возрастает.
С другой стороны, избавиться от null было бы заманчиво, т.к. ужасно надоели различные NullReferenceException и т.п. Отказ от null должен позволить повысить надежность программ и качество средств статического анализа кода.
В современных языках встраиваются средства null-безопасного программирования, так в языках Groovy и Fan есть оператор ?:

x = y?:z

x = y, если y != null и z в остальных случаях.
В Fan еще есть вариант null-безопасного вызова метода:

a?.method1()

Здесь если a == null, то результат будет null без вызова метода и дополнительных проверок. Это позволяет строить целые последовательные цепочки вызовов методов.
Но это скорее «синтаксический сахар», чем отказ от null. Мне удалось найти несколько статей от создателей упомянутого Хоаром Spec#, где предлагается техническое решение ряда проблем, связанных с типами, которые не могут содержать null. Единственное, чего я не представляю — как обойтись без null в тех случаях, когда это естественное следствие представления данных, например, последний элемент списка или дерева.