4 ms·

But... When Java gets "properly engineered solution" for async code... Kotlin got it as well!

• chrisseaton 6y ago
  So why bother using Kotlin? Seems like it fixes trivial things (makes simple classes a bit more terse) but retains the more fundamental problems and hangs on for Java to actually fix those.
  • dbsmith83 6y ago
    It's way more than terse classes. The syntax everywhere is cleaner. Higher order functions look so much nicer. Using val/var is superior to having to remember to write 'final' all the time. Kotlin also handles nullability way better. Ah, also, default arguments for constructors/methods. These features prevent a lot of developer mistakes, and thus better code is often achieved. Also, Kotlin usually forges ahead on features, and the Java is playing catch up. Take data classes for instance. If anything it seems like Kotlin gave Java a good kick in the pants to get it to start developing faster and adding modern language features.
    • pjmlp 6y ago
      Java and JVM are developed together, Kotlin just adds syntax sugar on top. If Kotlin is so much better, why doesn't JetBrains just port everything into Kotlin/Native?
      • dbsmith83 6y ago
        Because there are benefits to the JVM and interoperability with Java
        • pjmlp 6y ago
          Apparently not, given the cargo cult hate against Java on Kotlin community, glad to "leave Java behind".
  • The_Colonel 6y ago
    Kotlin fixes just trivial things - like nullability for example. Java still doesn't have a good solution, only about 5 bad ones and nothing is in sight. It even looks like Java designers simply don't consider it a problem anymore ... Instead, they focus on things like value types. Which are definitely cool, but they don't actually solve any of my problems. Typical business apps written in Java don't suffer from performance issues, they suffer from (accidental) complexity explosion and subsequent buginess (of which NPEs is a symptom).
    • erik_seaberg 6y ago
      When teams go so far as to consider alternatives to the JVM, memory footprint and poorly tuned GC are typical reasons.
  • listenallyall 6y ago
    If Kotlin's only improvement over Java were its scope functions, that alone would be an overwhelmingly good reason to migrate. Scope functions are awesome, cannot stress that enough. Kotlin syntax makes writing functional code beautiful and simple... map and fold and filter are so much easier to write than in any other language that also have the same functions, such as JS. Again, that alone would be enough to migrate. But there are still so many more simple, but incredibly useful functions like SubstringAfterLast which takes a nasty, ugly Split function into a beautiful, precise line of code. Just one example of many.
    • pjmlp 6y ago
      import static
• pjmlp 6y ago
  Not at all, because Kotlin wants to take it all, so they need to make the choice if they want to expose JVM features, or keep the language portable across all platforms that JetBrains wants to target with Kotlin. A good example is Kotlin/Native, by choosing a memory model incompatible with JVM code they failed, and were forced to go back into the drawing board for Kotlin/Native with a proper tracing GC.
  • balfirevic 6y ago
    If I were to use Kotlin server-side on JVM and didn't care about portability to other Kotlin platforms, could I not just use JVM green threads?
    • pjmlp 6y ago
      Depends on how Kotlin decides to expose them at the language level. For example, you need special syntax to use SAM types and Kotlin cannot use all use cases from interfaces with default methods. That is the thing with the Java Virtual Machine, the bytecodes and runtime are designed for Java, all guest languages have to pretend to be Java. Just disassemble the amount of boilerplate generated by the Kolin compiler.
      • vbezhenar 6y ago
        This is not always the case. One example is checked exceptions which are purely Java thing and do not exist in JVM (outside of metadata). That always amused me, it's like a switch to remove checked exceptions from language, you can turn it any time without backward compatibility issues. Another example is inner classes. Inner class can access private fields of outer class in Java. But in JVM there's no inner class concept, so compiler generates synthetic accessors for outer class private fields and inner class uses those methods to access private fields. That was fixed recently, though, but it was the case for many decades. Also I remember some funny bytecode with try-finally, I think it's implemented with gotos. Of course Kotlin generates a lot more boilerplate, that's for sure.