I could agree or disagree depending on how 'type erasure' is defined.
I'm firmly in the static-typing camp: Do the type-checking. Use the type information to generate good code, then throw away the types.
> And optionals.
What's your beef with Optionals? They didn't exactly go all-in on it. All the standard library stuff still returns nulls. I have one or two small beefs with Optionals, but my current peeve is IntelliJ warning me that I use them. (I KNOW I use them! I'm telling my callers which parameters they can include and which ones they can leave out.)
With optionals, I had hoped they would be a huge benefit to catching potential NPEs at compile time. But it was just lipstick. It was half assed. The reasoning was as you say - telling the caller about nulls - but IMO it adds complexity without benefit. They could have just defined a standard annotation. Or… made the compiler enforce them.
On the one hand, it is super hacky and requires ugly workarounds (passing Class<T> references around). At the same time, it also made creative abuses of the type system possible (e.g., heterogeneous lists). All while remaining type safe (albeit with runtime type checks).
It is also very noticeable how Java can iterate more quickly on its type system (only partially embedded in its VM) whereas C# generics are more or less set in stone (deeply embedded in its runtime).