3 ms·

> Kotlin has no mechanism to force error handling. I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the c

> Kotlin has no mechanism to force error handling. I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the compiler. This is pretty unique to Kotlin at the moment (honorable mention to Ceylon which offered similar support).

iainmerrick 6y ago
Unique to Kotlin? Don’t Swift and TypeScript have this feature too? Maybe it’s just the languages I’ve been working with this recently, but I think of this as something that’s breaking into the mainstream as language designers are starting to agree that it’s a good idea.
ragnese 6y ago
I like Kotlin's null most of the time, but I actually prefer Option still because every once in a while I need to nest them. You can nest Option, but not null.
valenterry 6y ago
I think you should look into some more programming languages before you claim that this is unique to Kotlin. ;)
dragonwriter 6y ago
> I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the compiler. Option/Maybe is enforced by the compiler on most languages that have it. Nullability as part of type signatures differs not because it is compiler-enforced, but because it is not nestable; it provides no equivalent of Maybe[Maybe[T]]. > This is pretty unique to Kotlin at the moment. C# 8, Python’s typing module, Java 8 via the Nullness Checker, Sorbet for Ruby, and lots of other statically-typed languages or static-analysis packages for languages (even dynamically-typed languages) provide nullability enforcement. It's definitely not unique to Kotlin.
- hota_mazi 6y ago
  > Option/Maybe is enforced by the compiler on most languages that have it. It's enforced by exactly zero languages. It's up to the developer to decide that their function should return an Option/Maybe instead of the naked value. By definition, any library construct is NOT enforced by the compiler, because... well, it's a library construct and not a language construct.
  - dragonwriter 6y ago
    > It's enforced by exactly zero languages. It's enforced in exactly the same way a nullability constraint is; if you don't use Maybe[T] instead of T , you can't use None (presuming T itself isn't Maybe[U]), just as if you don't use a nullable type you can't use null.

iainmerrick 6y ago

Unique to Kotlin? Don’t Swift and TypeScript have this feature too? Maybe it’s just the languages I’ve been working with this recently, but I think of this as something that’s breaking into the mainstream as language designers are starting to agree that it’s a good idea.

ragnese 6y ago

I like Kotlin's null most of the time, but I actually prefer Option still because every once in a while I need to nest them. You can nest Option, but not null.

valenterry 6y ago

I think you should look into some more programming languages before you claim that this is unique to Kotlin. ;)

dragonwriter 6y ago

> I was referring to nullability support, which is similar to Option/Maybe, except that it's enforced by the compiler. Option/Maybe is enforced by the compiler on most languages that have it. Nullability as part of type signatures differs not because it is compiler-enforced, but because it is not nestable; it provides no equivalent of Maybe[Maybe[T]]. > This is pretty unique to Kotlin at the moment. C# 8, Python’s typing module, Java 8 via the Nullness Checker, Sorbet for Ruby, and lots of other statically-typed languages or static-analysis packages for languages (even dynamically-typed languages) provide nullability enforcement. It's definitely not unique to Kotlin.

hota_mazi 6y ago
> Option/Maybe is enforced by the compiler on most languages that have it. It's enforced by exactly zero languages. It's up to the developer to decide that their function should return an Option/Maybe instead of the naked value. By definition, any library construct is NOT enforced by the compiler, because... well, it's a library construct and not a language construct.
- dragonwriter 6y ago
  > It's enforced by exactly zero languages. It's enforced in exactly the same way a nullability constraint is; if you don't use Maybe[T] instead of T , you can't use None (presuming T itself isn't Maybe[U]), just as if you don't use a nullable type you can't use null.