I once read that having nullable types is an absolute evil. I believe it was in an article written by the very person who created them(in Ada?) I believe this is the article
Anyway, so what if by default a language like C# used non-nullable types? How would you replace some of the common idioms in C# or Ruby or any other common language where null is an acceptable value?
Haskell is a powerful language that doesn't have the concept of nullity. Basically, every variable must be initialized to a non-null value. If you want to represent an "optional" variable (the variable may have a value but it may not), you can use a special "Maybe" type.
It's easier to implement this system in Haskell than C# because data is immutable in Haskell so it doesn't really make sense to have a null reference that you later populate. However, in C#, the last link in a linked list may have a null pointer to the next link, which is populated when the list expands. I don't know what a procedural language without null types would look like.
Also, note that many people above seem to be suggesting replacing nulls with type-specific logical "nothing" values (999-999-9999, "NULL", etc.). These values don't really solve anything because the problem people have with nulls is that they are a special case but people forget to code for the special case. With the type-specific logical nothing values, people STILL forget to code for the special case, yet they avoid errors that catch this mistake, which is a bad thing.
Realistically speaking, in any powerful programming language that allows pointers or object references in the first place, there are going to be situations where code will be able to access pointers which have not had any initialization code run upon them. It may be possible to guarantee that such pointers will be initialized to some static value, but that doesn't seem terribly useful. If a machine has a general means of trapping accesses to uninitialized variables (be they pointers or something else), that's better than special-casing null pointers, but otherwise the biggest null-related mistakes I see occur in implementations that allow arithmetic with null pointers. Adding 5 to a (char*)0 shouldn't yield a character pointer to address 5; it should trigger an error (if it's appropriate to create pointers to absolute addresses, there should be some other means of doing it).
