nilaway

Sure it does: https://github.com/uber-go/nilaway Not exactly the same solution as JSpecify, since it doesn't rely on annotations, but it's also more ergonomic. I'm not comparing this to "null-restricted types", since that's a draft JEP that hasn't made it even into a preview feature. Go also had multiple proposals for explicit nilability in types, and while they probably have less prospect of ever seeing the light of day compared to Project Valhalla, as things currently stand, Go is in the same position as Java: They are both extremely prone to NEPs out-of-the-box and they both have external tooling that can help you avoid them. Java null checkers have more comprehensive coverage potential compared to Go, but Go is the more ergonomic one here. You don't need a single extra annotation on your code.

This does exist, actually. https://github.com/uber-go/nilaway

The design of error handling in Go is interesting because they wanted to force people to actually handle errors by returning them as values, but then you as the programmer have to decide whether an error should be returned or a panic should be used. It reminds me of the original intention of checked exceptions in Java: checked exceptions are for things you force the caller to handle, unchecked exceptions are for "you the programmer messed up". In reality checked exceptions are pretty unpopular and can't be used in many situations, so people fall back to unchecked exceptions. If we equate unchecked exceptions with panics in Go, falling back to panics would be an anti-pattern in many cases. NPEs in Java have become rarer and rarer recently with the introduction of records (to easily create immutable classes, which are easier to validate for