3 ms·

I’m yet to forgive them for type erasure. And optionals. But I stopped using Java about 5 years ago, after 20 years of being increasingly frustrated with it, an

I’m yet to forgive them for type erasure. And optionals. But I stopped using Java about 5 years ago, after 20 years of being increasingly frustrated with it, and I couldn’t be happier.

klauserc 2y ago
I'm super torn about type erasure in Java. 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).
- neonsunset 2y ago
  What do you have in mind by "set in stone"? The emit strategy is implementation defined but pursuing true generics, particularly when using structs which are identical to Rust generics, allows C# to have optimal (monomorhpized) codegen when needed.
mrkeen 2y ago
> I’m yet to forgive them for type erasure. 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.)
- btbuilder 2y ago
  While it’s more how they are used, imo optional is abused to the point it adds complexity. You don’t avoid handling null, but now you have to deal with present or not. Therefore you’ve gone from 2 states to 3. Use of value or null is simpler to me and use of optional can be via Optional.of() rather than parameters and properties for the vast majority of cases.
- doctor_eval 2y ago
  The thing with type erasure is that reflection is a big part of Java - but it doesn’t work too well with generics. 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.

I’m yet to forgive them for type erasure. And optionals. But I stopped using Java about 5 years ago, after 20 years of being increasingly frustrated with it, and I couldn’t be happier.

klauserc 2y ago

I'm super torn about type erasure in Java. 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).

neonsunset 2y ago
What do you have in mind by "set in stone"? The emit strategy is implementation defined but pursuing true generics, particularly when using structs which are identical to Rust generics, allows C# to have optimal (monomorhpized) codegen when needed.

mrkeen 2y ago

> I’m yet to forgive them for type erasure. 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.)

btbuilder 2y ago
While it’s more how they are used, imo optional is abused to the point it adds complexity. You don’t avoid handling null, but now you have to deal with present or not. Therefore you’ve gone from 2 states to 3. Use of value or null is simpler to me and use of optional can be via Optional.of() rather than parameters and properties for the vast majority of cases.
doctor_eval 2y ago
The thing with type erasure is that reflection is a big part of Java - but it doesn’t work too well with generics. 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.