10 ms·

I'm not sure how "tongue in cheek" this article was supposed to be, but most of his issues with the problem can be solved by buying into the language. For: No

I'm not sure how "tongue in cheek" this article was supposed to be, but most of his issues with the problem can be solved by buying into the language. For: Not sure what he's upset about, but there are many options in the standard library. I almost never use the language construct for it, and I'm very happy with it. Nullable: I never expected nullable to completely save me from all issues. It has the same function as the @Nullable and @NotNull annotations (and all the other variants). It gives you a simpler way to reason about nullability, and forces you to respond to it; you can't just ignore it. Smart cast on mutable I get that this sucks, but they can't show it to happen. Yes, the chances are small, but there could be concurrency issues. They have to account for that, and can't tell if your code is multi threaded or not. Most of the time his issue can be solved with scoping, using ?.let or ?.apply Java Nullability What do you want from them? They have no ability whatsoever to control this. Either get annotations in the Java code if you can modify it (which is a good idea anyways), or wrap it and provide nullability information. Assignment is not an expression He got it. It's too protect against if(v=v). I know he makes a joke about automatic type casting, but if you're not assigning the result to anything, the logic in the if will still fail. Elvis operator I assume they removed Javas ternary operator to not get confused with the Elvis operator. ¯\_(ツ)_/¯ I kind of agree with him here unless I'm missing something Automatic type casting Frustrating, but safe Type alias I'm fine with it for simple cases, didn't want to parse his problem. Generics I hear his gripe, but at the end of the day Kotlin generics are Java generics. If there are some potential bugs in the compiler, report them and move on. Structure syntax I assume he means list and map literals. I agree it would be nice. Not sure why they didn't include it.

lmm 10y ago
> What do you want from them? They have no ability whatsoever to control this. Either get annotations in the Java code if you can modify it (which is a good idea anyways), or wrap it and provide nullability information. What I want is consistency. In Scala optional is always safe and null is never safe, and that's true whether you're calling a Scala method or a Java method (even the most perverse Java libraries don't declare themselves as returning Optional<String> and then return null). In Kotlin null is safe some of the time and not safe other times, e.g. if you're passing it to a method it might be fine or might not.
- Nycto 10y ago
  I don't see a huge difference between Scala's Options and Kotlin's null safety. In Scala, you can still do this: val x: Option[Int] = null
  - lmm 10y ago
    In theory you can. But you'd know to immediately fail that line in code review (or better still, enforce it at build time via wartremover). Whereas in Kotlin someMethod(null) might be perfectly legitimate or might not, but you can't tell without knowing the details of someMethod (whether it's a Java method or not).
    - afastow 10y ago
      Maybe I'm missing something but how is that different from Scala or Java? That will fail at compile time in Kotlin if the method is written in Kotlin and has a non-nullable parameter. Even if it's Java I think it will fail at compile time if the Java parameter is annotated with @NotNull. If it is a Java method and not annotated with @NotNull then of course it will be allowed at compile time because how could it possibly not be allowed? What are you saying is preferable in that case?
      - lmm 10y ago
        The trouble is in idiomatic Kotlin you have lines like that, because when you want to represent absence you use nullable parameters. So you can't assume a line like that is wrong. But you can't assume it's correct just because it compiled either, because as you say it might be an unannotated Java method. In idiomatic Scala you would never have a line like that (because you represent absence with optionals rather than null). So you can insta-fail any line like that in code review (or give very careful review in the rare case that it's calling a Java method that accepts a nullable parameter, but good modern Java libraries are moving away from those, so that case should go away).
        hota_mazi 10y ago
bitwize 10y ago
Most of the problems with INTERCAL can be solved by "buying into the language".

lmm 10y ago

> What do you want from them? They have no ability whatsoever to control this. Either get annotations in the Java code if you can modify it (which is a good idea anyways), or wrap it and provide nullability information. What I want is consistency. In Scala optional is always safe and null is never safe, and that's true whether you're calling a Scala method or a Java method (even the most perverse Java libraries don't declare themselves as returning Optional<String> and then return null). In Kotlin null is safe some of the time and not safe other times, e.g. if you're passing it to a method it might be fine or might not.

Nycto 10y ago
I don't see a huge difference between Scala's Options and Kotlin's null safety. In Scala, you can still do this: val x: Option[Int] = null
- lmm 10y ago
  In theory you can. But you'd know to immediately fail that line in code review (or better still, enforce it at build time via wartremover). Whereas in Kotlin someMethod(null) might be perfectly legitimate or might not, but you can't tell without knowing the details of someMethod (whether it's a Java method or not).
  - afastow 10y ago
    Maybe I'm missing something but how is that different from Scala or Java? That will fail at compile time in Kotlin if the method is written in Kotlin and has a non-nullable parameter. Even if it's Java I think it will fail at compile time if the Java parameter is annotated with @NotNull. If it is a Java method and not annotated with @NotNull then of course it will be allowed at compile time because how could it possibly not be allowed? What are you saying is preferable in that case?
    - lmm 10y ago
      The trouble is in idiomatic Kotlin you have lines like that, because when you want to represent absence you use nullable parameters. So you can't assume a line like that is wrong. But you can't assume it's correct just because it compiled either, because as you say it might be an unannotated Java method. In idiomatic Scala you would never have a line like that (because you represent absence with optionals rather than null). So you can insta-fail any line like that in code review (or give very careful review in the rare case that it's calling a Java method that accepts a nullable parameter, but good modern Java libraries are moving away from those, so that case should go away).
      - hota_mazi 10y ago

bitwize 10y ago

Most of the problems with INTERCAL can be solved by "buying into the language".