Try Core Data with Swift and you will see that happening. Lazy objects (vaults) are mapped from objc into Swift and will happily crash on something like a = b where both are not optional.
This is happening in objc code or in the swift part?
I'm not terribly surprised though, my one experience with core data was miserable once we strayed even a little from the happy path and I ended up rolling my own since we didn't need full functionality anyways. And this was for an internal app, at Apple ┐( ∵ )┌
Right, because the language has the "million dollar mistake" of nullable references by default, which you cannot change without breaking code. And the original comment was bemoaning that Go choose to to have nullable references by default too.
Unless something drastically changed in Scala 3, there is nothing to protect you from null in Scala.
In fact even Java is effectively safer thanks to all the null checking done by IntelliJ
Null is basically non-existent in idiomatic Scala. So technically you're right but besides calling Java libs there is only an infinitesimal small chance to get NPEs form Scala code. (Scala's NPE is the MatchException ;-)).
For Scala 3 there are improvements. It's "null safe" as long as you opt-in (modulo Java libs, and of course doing stupid things like casting a null to some other type).
So you actually complaining about people who don't know what they're doing? How is this related to Scala?
When you have people without clue on the team no language will safe you. You can also crash Haskell programs by throwing exceptions or just using List.head…