Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The real improvement is to lift nullability up to the type system. That way, every type acts as an optional by default, and the computer can infer when a nullable type has been null-checked.

This is what Kotlin does - it's truly freeing to work with.



They are slowly getting there. See the JEP draft: Null-Restricted Value Class Types (Preview)

Source: https://openjdk.org/jeps/8316779

But it is already possible today using the Spring annoation "NonNullApi" on a package level. Then, you can allow nullable fields via @Nullable.

It's not perfectly elegant, but it works surprisingly well.


Usually I have bigger fish to fry in enterprise projects than a couple of NullReferenceExceptions.

What would be truly freeing is getting the right set of folks on the projects.


"the real fix is to move from the stone age to the iron age"

...suffice it to say, there are even better ages


I don't know, I think Kotlin strikes a pretty good balance as far as languages go. What's your preference over it?


oh I think it's fine. I just find it a bit odd to be saying "the thing we should have from our type system is that it's a type system, it's truly freeing to work with". Like... yeah of course we should but it's a bit sad that we're getting exciting over basic functionality like that in 2025.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: