6 ms·
I've never used Kotlin (and I haven't touched Java in more than a decade) so I can't really comment on the usability issues of the language. That being said I t
by simias 10y ago
I've never used Kotlin (and I haven't touched Java in more than a decade) so I can't really comment on the usability issues of the language. That being said I think he completely misses the point of the nullable types and he's fighting them because he's treating them like "void * " instead of trying to understand how to work with them.
In particular, to his:
> Where does this absolutely crazy confidence of a compiler that each character of my program is an element of multithread concurrency come from?
I'd reply: why would the compiler have this absolutely crazy confidence that a particular character of your program isn't an element of a multithread concurrency? Why do you want your compiler to make assumptions about your code if it's not able to enforce them?
I don't know what's the right way to write what he means in Kotlin but in Rust it'd be something like:
match (value) {
Some(v) => v,
None => 0
}
Or alternatively:
value.unwrap_or(0)
Which are both safe and, in my opinion, clearer than the proposed code in TFA. I would assume that Kotlin has a similar syntax for that use case?
That being said I can imagine that having to interface with Java (which doesn't share the same "mindset") might be frustrating. It helps when all the language and its libraries are designed from the ground up around a certain paradigm.
- algesten 10y agoI agree. I used to argue like the author, that null is a thing in computing and I just had to deal with it. But after spending some time in Rust and Swift, I learnt a whole new way of thinking about it. The killer combination is: no null + immutable I've taken this to javascript, and it is so much better. Just don't accept null values anywhere in the model code, and suddenly writing view code is super easy. No more endless if-cases or ternary to deal with nulls.
- gagege 10y agoYes. I usually refer to them as "optional" values, rather than "nullable" values. Something should only be null if it is truly optional to the class, view or whatever, which is a pretty rare thing. If a class requires a certain value to be able to do it's work, and that value is missing (null), why was the class even instantiated? That should be a big no-no.
- djsumdog 10y agoYou can do that exact same matching in Scala (except it's value match { case Some(...}), and the great way to avoid things changing are to use non-mutable types (a val instead of a var). I have not played much with Kotlin, but I feel like Scala deals with a lot of the issues he brings up already (although it has a ton of issues itself; some stemming from it being so tied to the underlying Java Runtime and others from bad design decisions).
- Sharlin 10y agoIt's painful for the compiler to assume non-local variables may always be shared if the language does not reify the concept of "sharedness" like Rust does. Given that in any reasonable program the vast majority of state is non-shared, it really is somewhat unreasonable for the compiler to always assume the worst without the programmer even being able to override it.
- cel1ne 10y agoIn Kotlin you can do: when (value) { 1 -> ..., 2 -> ..., null -> ... } The compilers doesn't let you forget to check for null. It's smart enough to correctly evaluate and cast nested expression. when (value) { is null -> "nothing to see" is Number -> "a Number: ${value + 1}" is String -> when { it.isBlank() -> "Blank String" null -> /* compiler error, you already checked for null */ else -> it.trim() } } Or val x = value ?: 5 /* use 5 if value is null) val x = value?.some?.nullable?.chain ?: 5 /* use 5 if the chain can't be called */ Or val x = value?.let { /* work on non-null value */ } ?: alternative