Why Kotlin Sucks

Comments

1. 

   Matjaž Domen Pečan 6:21PM on Wednesday, Mar 15, 2017

   Null checks: you are doing it wrong: return value ?: 0 or val nonNullValue = value ?: return 0 return nonNullValue The map example: You can use the to infix instead (eg. “file1” to 0).

   About the generics: did you check out reified functions?

   Reply
2. 

   Panda 1:32AM on Friday, Mar 17, 2017

   For: I’m not entirely sure what you’re trying to say here. Those two do, in fact, function identically for those use cases. It exists because it’s incredibly useful and actually much more powerful and expressive than C-Style for loops. You can do anything with Progressions in a much more readable way:

   for (int i = 0; i 

   for (i in 0 until 100 step 2) {
   
   }
   

   Nullability: I’m going to assume that your example code has a typo in it, considering that code very obviously would not work as is. You probably meant value == null. I’ll continue with that assumption…

   “Where, how and by what can this property be modified between these two strings??!!! By a neighboring thread?” Yes. Especially in a JVM language, it is wrong to think that code will not exist in a multithreaded environment.

   Furthermore, this “problem” is trivially solved by the elvis operator:

   fun F() : Int {
       return value ?: 0
   }
   

   I must admit I didn’t quite understand what you were getting at in the rest of this section. Perhaps you should research Kotlin’s platform types?

   Assignment Expression: You refer to if as pathetic, just for fun I guess. Assignment is not an expression because it easily leads to confusion and has a very limited use.

   Conditional Operator: Your only reason to have the conditional operator is that it exists in other languages. This cannot stand on its own when other (clearer, imo) solutions are presented. Having both if expressions and the conditional operator is redundant.

   Why Was Automatic Type Casting Killed? Because implicits suck. A lot.

   Type Aliases: Your arguments here are valid, and I agree with them. Nested and local type aliases will be supported in the future.

   Generics I encourage you to rewrite this section after researching Kotlin’s reified generics.

   Structures Syntax Another section that displays your lack of understanding for the language. Take a look at the to function for your maps.

   Reply
3. 

   Ole Kristian Sandum 2:52PM on Sunday, Mar 19, 2017

   Hmm. Kotlin inserts runtime checks and fails fast to ensure no bad values propagate through the system to surprise you at a later time, and you somehow find this to be a bad thing?

   Reply
4. 

   Dale King 5:50PM on Tuesday, Mar 21, 2017

   A lot of your problem is not so much with the particular construct you are talking about, but really about mutability. Mutable state is something that is problematic in the modern age of multiple cores and memory caches. Many of your very intuitive assumptions about the state of variables when modified in multiple threads may have worked in the old days of single core processors and un-cached memory, but can be very wrong on current hardware and getting it correct can be very difficult.

   So Kotlin, does the correct thing and encourages a functional programming style and discouraging mutable state. It doesn’t force it on you, but if you declare a variable as mutable, it is not going to make assumptions for you like that accessing the same mutable variable in successive statements will retrieve the same value, because there is no guarantee that is the case. If you declare variables mutable it can lead to more work on your part and that is a good thing. For more info, google functional programming mutable state to find volumes written on the subject.

   Now for more specifics:

   For: As Panda said there is nothing wrong here. The simple cases of for are covered in a functional way (no visible mutable state). The for( x in y ) syntax is really there to be familiar to those coming from Java that has a similar construct. The more usual way to write those in Kotlin would be:

   list.forEach{ println(it) }
   arr.forEach{ println(it) }
   (0..10).forEach{ println(it) }
   

   or even:

   list.forEach(::println)
   

   You can certainly do more complex things with C-style for loops, but when doing so it is rarely easy to understand. For more complex loops the better alternative in Kotlin is tail recursive functions that get compiled down to the way you would write it as a loop but with the inherent thread safety of immutable state.

   Null: Once again, the issue here is mutability. You expect the compiler to assume that multiple access to the same mutable property to return the same value, which would be very bad. The simple solution to that is to get the value once and use that value which cannot change.

   Your first case Panda already addressed where it can trivially be replaced with:

   fun F() = value ?: 0
   

   Your second case can be handled with the let extension function:

   fun F()
   = value?.let {
         when (Random().nextInt()) {
          3    -> it + 2
         12   -> it + 1
          5    -> it * 4
          else -> 0
      } ?: 0
   

   Assignment as expression: Once again the reason has to do with mutability. Having assignment an expression means you can bury the mutation of state within some larger expression. Since Kotlin favors immutability it says if you are going to mutate state it has to be a statement by itself.

   if vs. ?: if is much more readable. This has been discussed to death on Kotlin forums. Conditional operator only existed because if was not an expression in other languages. With if as an expression no need for both.

   No implicit conversion between primitives: On the fence myself on this one as well. While I understand it, in practice it is a bit of a pain

   typealias: Agreed. They are currently limited, but what they do now is important, which is to be able to give a better name to more complex type. They are still a work in progress however

   Generics: Yes they inherit Java’s form of generics, but they do get reified types in inline methods which is awesome. Your first example is stupid, you declare a generic type that takes a parameter of any object and later are surprised when the compiler didn’t contradict you.

   1. Why didn’t it crash during the first call, where Double is passed instead of Int? Because you said the parameter was of type Any. Change the parameter type to T and it won’t compile because you are passing an incompatible type. But the reason it doesn’t fail is that doubles can be cast to int and they get truncated. No great surprise here.

   2. Why the try/catch block was not performed? Because of Java generics the generic type is not retained at runtime. The cast will never fail, which is why the compiler is giving you a warning. It is telling you that this cast will not be checked (i.e. an unchecked cast warning).

   Your other example just shows to me that Kotlin is better than Java and detects errors earlier like Ole said.

   Structures: as Panda pointed out your map example can be:

    val tree = mapOf(
      "dir1" to mapOf("file1" to 0, "file2" to 1),
      "dir2" to mapOf(
         "dir21" to mapOf("file1" to 0, "file2" to 1),
         "dir22" to mapOf("file1" to 0, "file2" to 1) ) )
   

   While this is somewhat verbose it is light years ahead of Java which has no such facility.

   Reply
5. 

   Dale King 6:23PM on Tuesday, Mar 21, 2017

   Let’s try it again with line breaks:

   A lot of your problem is not so much with the particular construct you are talking about, but really about mutability. Mutable state is something that is problematic in the modern age of multiple cores and memory caches.

   Many of your very intuitive assumptions about the state of variables when modified in multiple threads may have worked in the old days of single core processors and un-cached memory, but can be very wrong on current hardware and getting it correct can be very difficult.

   So Kotlin, does the correct thing and encourages a functional programming style and discouraging mutable state. It doesn’t force it on you, but if you declare a variable as mutable, it is not going to make assumptions for you like that accessing the same mutable variable in successive statements will retrieve the same value, because there is no guarantee that is the case. If you declare variables mutable it can lead to more work on your part and that is a good thing. For more info, google functional programming mutable state to find volumes written on the subject.

   Now for more specifics:

   For: As Panda said there is nothing wrong here. The simple cases of for are covered in a functional way (no visible mutable state).

   The for( x in y ) syntax is really there to be familiar to those coming from Java that has a similar construct. The more usual way to write those in Kotlin would be:

   list.forEach{ println(it) }
   arr.forEach{ println(it) }
   (0..10).forEach{ println(it) }
   

   or even:

   list.forEach(::println)
   

   You can certainly do more complex things with C-style for loops, but when doing so it is rarely easy to understand. For more complex loops the better alternative in Kotlin is tail recursive functions that get compiled down to the way you would write it as a loop but with the inherent thread safety of immutable state.

   Null: Once again, the issue here is mutability. You expect the compiler to assume that multiple access to the same mutable property to return the same value, which would be very bad.

   The simple solution to that is to get the value once and use that value which cannot change. Your first case Panda already addressed where it can trivially be replaced with:

   fun F() = value ?: 0
   

   Your second case can be handled with the let extension function:

    fun F() = value?.let {
        when (Random().nextInt()) {
            3 -> it + 2
            12 -> it + 1
             5 -> it * 4
             else -> 0
        } ?: 0
   

   Assignment as expression: Once again the reason has to do with mutability. Having assignment an expression means you can bury the mutation of state within some larger expression. Since Kotlin favors immutability it says if you are going to mutate state it has to be a statement by itself.

   if vs. ?: if is much more readable. This has been discussed to death on Kotlin forums. Conditional operator only existed because if was not an expression in other languages. With if as an expression no need for both.

   No implicit conversion between primitives: On the fence myself on this one as well. While I understand it, in practice it is a bit of a pain.

   typealias: Agreed, they are currently limited, but what they do now is important, which is to be able to give a better name to more complex type. They are still a work in progress however

   Generics: Yes they inherit Java’s form of generics, but they do get reified types in inline methods which is awesome.

   Your first example is stupid, you declare a generic type that takes a parameter of any object and later are surprised when the compiler didn’t contradict you.

   1. Why didn’t it crash during the first call, where Double is passed instead of Int? Because you said the parameter was of type Any. Change the parameter type to T and it won’t compile because you are passing an incompatible type. But the reason it doesn’t fail is that doubles can be cast to int and they get truncated. No great surprise here.

   2. Why the try/catch block was not performed? Because of Java generics the generic type is not retained at runtime. The cast will never fail, which is why the compiler is giving you a warning. It is telling you that this cast will not be checked (i.e. an unchecked cast warning).

   Your other example just shows to me that Kotlin is better than Java and detects errors earlier like Ole said.

   Structures: as Panda pointed out your map example can be:

   val tree = mapOf(
       "dir1" to mapOf("file1" to 0, "file2" to 1),
       "dir2" to mapOf(
           "dir21" to mapOf("file1" to 0, "file2" to 1),
           "dir22" to mapOf("file1" to 0, "file2" to 1) ) )
   

   While this is somewhat verbose it is light years ahead of Java which has no such facility.

   Reply
6. 

   Dale King 6:27PM on Tuesday, Mar 21, 2017

   Sorry for the double reply, but after I commented it showed me my comment with whitespace all replaced by spaces

   Reply
7. 

   David William Cowden 5:25PM on Thursday, Mar 23, 2017

   Feels like a rant written by someone who likes Java and takes it as an axiom that Kotlin should be viewed as a Java preprocessor not a distinct language. In other words, someone who’s happy writing Java from 25 years ago. There’s no commentary on how the patterns that Kotlin enables mean you avoid half the issues you gripe about in the first place. And WTF is wrong with type aliases when functions are actually types (of course it’s unnecessary if everything is a class, but that’s not how Kotlin rolls)? That said, I do really miss the ternary operator.

   Reply
8. 

   Adam McNeilly 6:30PM on Thursday, Mar 23, 2017

   Regarding this snippet:

   It compiles fine without any errors or warnings, but then crashes with the standard NullPointerException during the runtime, since Kotlin does not check anything, anywhere. But where’s the promised, or rather declared, safety?!

   Well, you’re dealing with a Java class that can return null, and using it in a Kotlin class. Kotlin wants to maintain full interoperability with Java, so they relax the null type. From the docs: Null-checks are relaxed for such types, so that safety guarantees for them are the same as in Java.

   https://kotlinlang.org/docs/reference/java-interop.html#null-safety-and-platform-types

   Reply
9. 

   Adam McNeilly 6:31PM on Thursday, Mar 23, 2017

   relax null check*

   Reply
10. 

    Dale King 2:08AM on Friday, Mar 24, 2017

    Regarding the removal of implicit conversions between, one example that they give in one talk is this Java code which was part of a Java Puzzler question:

    StringBuilder sb = new StringBuilder('P');
    sb.append('a'); 
    sb.append('i');
    sb.append('n');
    System.out.println(sb.toString());
    

    It may be surprising that this code does not print “Pain”, it prints “ain”. This is because StringBuilder does not have a constructor that takes a character. It has one that takes an int to specify the initial capacity and that is the one called, because Java implicitly converts char to int.

    So I can certainly agree with no implicit conversions with characters, but the case is a bit more difficult for forbidding implicit widening conversions (e.g. byte -> int), but it can be argued that it forces you to decide do I want to treat the byte as signed or unsigned. Except that they don’t provide mechanism for easily converting a byte to int treating the byte as unsigned (i.e. no toIntUnsigned() method).

    When going from integral to floating point there are also some non-intuitive cases due to loss of precision like this:

    double x = (double) Long.MAX_VALUE;
    long y = Long.MAX_VALUE - 1;
    
    println(x == y)
    

    which prints false because not all long values can be represented in double.

    Reply
11. 

    Terrence King 3:54PM on Tuesday, Sep 18, 2018

    For such a good programmer who can differentiate good from bad and whose opinion is worth something (hint: sarcasm), this website is one of the worst websites I ever visited. Basically invalidates everything you write about programming.

    Reply