Safe Rust doesn't have any either, though presumably you'll say "but unsafe" there.
> It is generally desirable to keep invalid objects properly typed
As written this doesn't mean anything, if the object is properly typed then it is valid, an invalid object can't be properly typed. So more likely you're imagining something like Rust's MaybeUninit<T> type wrapper which says well, either this is a T, or it isn't (yet) and so a programmer will need to tell the compiler once they've arranged that it is a T so then it can be used as a T.
Barry Revzin has (I think) landed the fixes to the C++ type system so that you could reasonably write this in C++ too once you have C++ 26.
For example: Dynamic memory allocation can fail. Input might fail. Input validation might fail. Hence, any object with dynamically allocated memory and any object processing input might become invalid in that sense.
You have to deal with such cases in any programming language and the source of error is the same in any of them. Nil is not an "additional source of error" or anything like that. Inadequate typing of nil (instead of having option types) might create an additional source of error but that depends on the language and it doesn't need to.
On a side note, those type system fixes may be neat for people who like typed logics but they are mostly pointless because the invalid state occurs at runtime.
Your world becomes a bewildering mess in which it seems as though nothing can ever be trusted, and so you stumble into either writing endless checks because you're never sure of anything, or you throw your hands in the air and pronounce doing nothing "good enough" then blame others when inevitably your software doesn't work.
Take Rust's Allocator::allocate, defined as:
fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError>;
To address the content: Yes, you have to deal with that error result just like you have to deal with a nil pointer. No difference. That's the point.
By the way, the toxic behavior of the Rust community is one of the reasons why I barely use the language.
In an alternative universe, there could be n sentinel non-values, instead of a single null.
There could be "null" ("I am initialising this memory as uninitialised"), but there could also be "egad" ("this pointer refers to memory on a different page"), there could be "biff" ("this address is on another caller's stack").
There are infinite ways you could design a language which lets you take invalid memory and tell the type system it's a Sheep, when it's not. Some of those languages might even have sophisticated biff-checkers or raise EgadReferenceExceptions.
What's stopping you from throwing out null along with biff and egad?
Obviously we should be able to represent objects with possibly invalid state, but rather than allowing a "possibly invalid value" as a legitimate member of a huge number of types, which is what nil/null permits, the possible invalidity should be it's own type, like a MaybeInvalid<T>. Even languages that bake null checking into the type system are doing this, and then just inserting implicit conversions to/from such a type.
I think that's the bigger issue in Java. `int` can't be used in generics, so now you use the boxed type `Integer` which needs to be checked on each use, which depending on the usage is a lot of work.
If Java had proper generics without this workaround, we wouldn't have nearly as many issues.