Those just are not enough for many of us to warrant the switch. Mutability is fine if you’re not going over thread boundaries, many of us don’t struggle with null, and brevity does not always equal clarity.
Null safety at application level is just a good architecture, test coverage and regular code reviews. It is not an internalized struggle of any sort. Last time I saw uncaught NPE in server logs was a long time ago: why would it necessarily be more frequent than some data validation error?
> Null safety at application level is just a good architecture, test coverage and regular code reviews.
Anything relying on that is brittle. I work on a 20 years old code base with the majority of the base classes being 15+ years old. This is exactly where Java should shine, and it's not doing bad, but it's very hard to enforce top-notch coding standards across ~200 devs committing during that time frame.
As a result, there isn't much of an information on the nullability of return types, and you end up defensively handling nulls everywhere which is just noise.
> Last time I saw uncaught NPE in server logs was a long time ago
Luckily these are rare also for us, I guess most are caught during development and then on some test environment / CI, but catching these anytime later than compilation is way too late. The cost of a bug is directly connected with time between introduction and fixing it.
> I understand that, but for starting new projects the equation can be different.
I don't think for new projects the equation is any different. Why would I throw away a language and ecosystem that I understand, that I'm productive in and with language designers that I trust to do the correct thing for the future? Why go learn another language and ecosystem when the things it brings to the table are of no value _to me_ ?
I honestly do not struggle with null. If you actually read the code you call and test the code you write you won't have a problem.
It's very hard to take you seriously if your argument is "just read the code you call to figure out if it returns null or not". That just isn't feasible in large code bases.
It sounds like badly documented code then. A function, especially if some kind of API boundary, should absolutely state whether it can or can’t return null.
Ideally everything should be non-nullable, with optionally specified nullability.
> It sounds like badly documented code then. A function, especially if some kind of API boundary, should absolutely state whether it can or can’t return null.
Of course, in the type system.
Just like we're "documenting" types themselves in the type system and not in JavaDocs.
I have worked at over a dozen companies where they were using Java. I have yet to see one where null checks and error handling thanks to said null checks doesn't occupy a significant percentage of the application. Maybe I am unlucky, or maybe you've done so much Java now you don't even read the null checks and attached error handling everywhere.
Maybe our definition of significant percentage is different, but I honestly don’t find it too much.
A notable exception is some kind of generated objects, from say, wsdls getting transformed to different dtos, but in this case MapStruct is a godsend, and is overall less error-prone than doing it even in a null-safe language. (Manually copying fields won’t tell you if a new field is added that should also be copied, for example).
I think you’re just unlucky. Having compiler enforced null checking does not reduce the amount of nulls you need to check. They will still be everywhere and you will still have instances where people will not check null from a nullable function with !! because they believe their input won’t give them null back.
> Having compiler enforced null checking does not reduce the amount of nulls you need to check.
If a function in a null-safe language is declared to return "String", then it signals that, effectively, you don't have to check for null. So, yes, compiler-enforced null safety does reduce the amount of nulls you need to check.
The trick, of course, is to not make everything nullable, but as few things as possible.
In Kotlin, of course, this is only true up to the point where Java interop might interfere with it (because Kotlin might infer a Java return type to be non-nullable when it's in fact nullable).
