4 ms·

> In Scala you're forced to check Options But you're never forced to use them. That's the main problem with Scala's approach: it's entirely er... optional. Th

> In Scala you're forced to check Options But you're never forced to use them. That's the main problem with Scala's approach: it's entirely er... optional. The Scala compiler will never tell you "You can't write a.foo() because a may be null". > Only from a Java library and that's exactly the same problem in Kotlin No, it's not. The Kotlin compiler will not let such values enter Kotlin code until you've told it precisely whether that type is nullable or not. Scala has no such mechanism so null values can enter Scala code without the compiler having any say over it.

lmm 10y ago
> But you're never forced to use them. Use wartremover, then you are. Or just never write "null" (or check for it in code review). Yes ideally it just wouldn't be there, but it's really not hard to avoid it. > The Scala compiler will never tell you "You can't write a.foo() because a may be null". But you'll never get yourself into a position where a may be null (unless a came from a Java library, but that exact same problem can happen in exactly the same way in Kotlin). If you need to represent absence you'll use Option, and the compiler won't let you write a.foo() if a is an Option. > No, it's not. The Kotlin compiler will not let such values enter Kotlin code until you've told it precisely whether that type is nullable or not. No it doesn't. It lets you silently treat a type returned from a Java library as non-nullable.
- hota_mazi 10y ago
  > Use wartremover, then you are. Well, yes, that's my point: that the Scala compiler can't do it, so you need an external tool to do it for you. It's a similar argument to a dynamic language programmer saying their language is statically typed, you just need to use that external tool to type check it. > But you'll never get yourself into a position where a may be null (unless a came from a Java library, but that exact same problem can happen in exactly the same way in Kotlin) Again, no it can't. Types coming from Java are marked as "platform types" by the Kotlin compiler and they are not allowed in the Kotlin code base. You need to convert them to a bona fide Kotlin type first (basically, decide if it's a nullable type or not). It's the third time I've mentioned this and you keep ignoring it. In contrast, Scala happily lets Java types enter the Scala object world, along with its null values.
  - lmm 10y ago
    > Well, yes, that's my point: that the Scala compiler can't do it, so you need an external tool to do it for you. It's a compiler plugin so the compiler can do it, it just needs a little configuration. And in practice you don't need it. > It's a similar argument to a dynamic language programmer saying their language is statically typed, you just need to use that external tool to type check it. No it isn't, at all. The reason that doesn't work for dynamic languages is a) they tend to use inherently dynamic constructs that can't be safely typed b) the library ecosystem often isn't typed or is typed inaccurately. Neither of these things happens in Scala. The ecosystem doesn't use null, no-one uses null in their code, it's a complete and utter non-problem. It's like the "haskell is no safer than anything else because you can still call unsafePerformIO" nonsense. > Types coming from Java are marked as "platform types" by the Kotlin compiler and they are not allowed in the Kotlin code base. You need to convert them to a bona fide Kotlin type first (basically, decide if it's a nullable type or not). Yes except they're implicitly convertible to non-nullable. So in practice it's no better than treating them as non-nullable.

lmm 10y ago

> But you're never forced to use them. Use wartremover, then you are. Or just never write "null" (or check for it in code review). Yes ideally it just wouldn't be there, but it's really not hard to avoid it. > The Scala compiler will never tell you "You can't write a.foo() because a may be null". But you'll never get yourself into a position where a may be null (unless a came from a Java library, but that exact same problem can happen in exactly the same way in Kotlin). If you need to represent absence you'll use Option, and the compiler won't let you write a.foo() if a is an Option. > No, it's not. The Kotlin compiler will not let such values enter Kotlin code until you've told it precisely whether that type is nullable or not. No it doesn't. It lets you silently treat a type returned from a Java library as non-nullable.

hota_mazi 10y ago
> Use wartremover, then you are. Well, yes, that's my point: that the Scala compiler can't do it, so you need an external tool to do it for you. It's a similar argument to a dynamic language programmer saying their language is statically typed, you just need to use that external tool to type check it. > But you'll never get yourself into a position where a may be null (unless a came from a Java library, but that exact same problem can happen in exactly the same way in Kotlin) Again, no it can't. Types coming from Java are marked as "platform types" by the Kotlin compiler and they are not allowed in the Kotlin code base. You need to convert them to a bona fide Kotlin type first (basically, decide if it's a nullable type or not). It's the third time I've mentioned this and you keep ignoring it. In contrast, Scala happily lets Java types enter the Scala object world, along with its null values.
- lmm 10y ago
  > Well, yes, that's my point: that the Scala compiler can't do it, so you need an external tool to do it for you. It's a compiler plugin so the compiler can do it, it just needs a little configuration. And in practice you don't need it. > It's a similar argument to a dynamic language programmer saying their language is statically typed, you just need to use that external tool to type check it. No it isn't, at all. The reason that doesn't work for dynamic languages is a) they tend to use inherently dynamic constructs that can't be safely typed b) the library ecosystem often isn't typed or is typed inaccurately. Neither of these things happens in Scala. The ecosystem doesn't use null, no-one uses null in their code, it's a complete and utter non-problem. It's like the "haskell is no safer than anything else because you can still call unsafePerformIO" nonsense. > Types coming from Java are marked as "platform types" by the Kotlin compiler and they are not allowed in the Kotlin code base. You need to convert them to a bona fide Kotlin type first (basically, decide if it's a nullable type or not). Yes except they're implicitly convertible to non-nullable. So in practice it's no better than treating them as non-nullable.