3 ms·

Module global variables, I think we can agree, are less than ideal. But I was thinking of class fields. I don't really want my compiler to hold my hand with re

Module global variables, I think we can agree, are less than ideal. But I was thinking of class fields. I don't really want my compiler to hold my hand with respect to "nullable", if I know for a fact that, by the time the code gets there, it can't possibly be null. Think of it this way: It's not a compile error to access an int from multiple threads, right? It doesn't require that !! syntax if you're just accessing a mutable class field or variable? So if I test an int for a value and then do something that assumes the value is still the same, I'm writing something that could crash just as easily as the null reference -- and array out-of-bounds, or a flag that says it's OK to do something but that flag changes after I check it, because I didn't grab a mutex. So why does it add an error condition if you're accessing a mutable variable that's available in multiple threads just because it's nullable? Seems like extra busy work for no clear benefit for what is, as you say, a rather rare situation. If we're going to share data across threads, I'd rather the language not present a false sense of security as a result of the !! operator.

pdpi 10y ago
I think you misunderstood me — the rare situation is the compiler complaining about valid code. In practice, I find null handling in Kotlin to be quite straightforward, and it simplifies both writing and reading code a fair bit. I also find that forcing me to opt in to allowing nulls and, therefore, complicating my code a bit (by correctly handling them in the implementation) forces me to clean up my designs a bit. Now, Jetbrains don't claim to solve data races in general, so it's fine to not solve all of them. But they _do_ claim to provide null safety in general (modulo java interop), so they _must_ provide null safety in the face of data races. I do agree that a language that solves data races in general is very, very valuable (and that's part of the reason why I've invested some time learning Rust), but solving nulls better than the half-arsed solution present in java Optional is, IMO, still quite valuable. Finally, what do you mean by "a false sense of security as a result of the !! operator"? The !! operator is effectively "I know for a fact this isn't null, stop bothering me", and, when you read it, it should raise alarm bells, rather than make you feel safe. I also object to the notion that a language that is a bit safer is bad because it lulls you into a false sense of security. That's like saying that GCs are bad because they lull you into a false sense of security from memory leaks.

pdpi 10y ago

I think you misunderstood me — the rare situation is the compiler complaining about valid code. In practice, I find null handling in Kotlin to be quite straightforward, and it simplifies both writing and reading code a fair bit. I also find that forcing me to opt in to allowing nulls and, therefore, complicating my code a bit (by correctly handling them in the implementation) forces me to clean up my designs a bit. Now, Jetbrains don't claim to solve data races in general, so it's fine to not solve all of them. But they _do_ claim to provide null safety in general (modulo java interop), so they _must_ provide null safety in the face of data races. I do agree that a language that solves data races in general is very, very valuable (and that's part of the reason why I've invested some time learning Rust), but solving nulls better than the half-arsed solution present in java Optional is, IMO, still quite valuable. Finally, what do you mean by "a false sense of security as a result of the !! operator"? The !! operator is effectively "I know for a fact this isn't null, stop bothering me", and, when you read it, it should raise alarm bells, rather than make you feel safe. I also object to the notion that a language that is a bit safer is bad because it lulls you into a false sense of security. That's like saying that GCs are bad because they lull you into a false sense of security from memory leaks.