5 ms·

The Hitchhiker's Guide to Kotlin

93 points by minnca 5y ago

nassimsoftware 5y ago
Kotlin is a really nice language. I wish it was used more especially that now it isn't just limited to the Android and Java ecosystems. Kotlin can now compile to native binaries : https://kotlinlang.org/docs/native-overview.html#sharing-code-between-platforms https://kotlinlang.org/docs/native-overview.html#sharing-cod... Kotlin can now compile to Javascript : https://kotlinlang.org/docs/js-overview.html https://kotlinlang.org/docs/js-overview.html Edit : You can even use React with Kotlin : https://kotlinlang.org/docs/js-get-started.html https://kotlinlang.org/docs/js-get-started.html Kotlin can now be used for datascience as well (You can run kotlin code in a jupyter notebook) : https://kotlinlang.org/docs/data-science-overview.html#libraries https://kotlinlang.org/docs/data-science-overview.html#libra...
- pjmlp 5y ago
  Kotlin/Native is hardly a stable target, given that they botched the implementation by going with an incompatible memory model as Java, and have spent the last year fixing it by rebooting it with a proper GC implementation. Hardly any better than just using GraalVM or any other JVM AOT compiler, some of which go back to early 2000's even if only available in commercial JDKs. The JavaScript compilation target still needs to do some catching up with TypeScript.
  - nassimsoftware 5y ago
    What catching up is required compared to TypeScript? Could you go in bit more details on that, I'm curious.
    - pjmlp 5y ago
      Ecosystem, tooling, libraries.
      - smallerfish 5y ago
        It's actually very good - debugging from the IDE now even works. I'd recommend building around KVision rather than raw KotlinJs (https://kvision.gitbook.io/kvision-guide/ https://kvision.gitbook.io/kvision-guide/). The main thing that can be annoying is figuring out module exports from a js library that you want to use (which is probably easy enough if you have a modern javascript background). I haven't found a library that's stumped me yet, but some are more annoying than others. Jetbrains have a tool called Dukat which will supposedly one day automate this, but for now it's not there. Distribution size can be an issue, but it's not terrible. My current (moderately complex) app is floating at around 2MB. I haven't tried splitting it up, though that is possible.
        pjmlp 5y ago
        Except the platform is JavaScript, and TypeScript is basically Web IDL aware compiler on steroids, no need to use anything that adds even more layers.
        smallerfish 5y ago
        That depends. If the rest of your application is in Kotlin, you're reducing cognitive overhead. Same language, same compile, same distribution. You can share view models between frontend and backend. It's much closer to what GWT promised to be than GWT ever was.
        pjmlp 5y ago
        Guest languages are always an impedance mismatch with the underlying platform. I don't buy into sharing source files instead of clean separation via Web APIs, the additional tooling complexity isn't worth the pain. I did vote against stuff like GWT already several times, and every time it has been proven to have been the right decision, when things went hot.
        smallerfish 5y ago
  - erpellan 5y ago
    I feel the non-JVM targets are a real distraction from what is a lovely language. I’d rather they focussed more on fixing the issues with kotlin in IntelliJ - you’d think controlling both the language and the IDE would result in a less buggy experience than the current situation.
    - pjmlp 5y ago
      I agree, to me it feels just like JetBrains turned Borland just before the Inprise Corporation makeover.
    - zorr 5y ago
      Could you elaborate on specific issues you have with Kotlin/IntelliJ? I use both as my daily work environment and I barely have issues.
      - erpellan 5y ago
        It frequently loses track of libraries, claiming large chunks of the codebase won’t compile until caches are cleared and it is restarted. It gets stuck indexing forever, losing all code completion and navigation abilities until it’s restarted. Git integration sometimes stops working. It will list the files to be committed but does nothing when you click commit, until it’s restarted. Exiting presentation mode leaves the font set to a huge size (until it’s restarted).
  - lokedhs 5y ago
    My personal open source evening hacking project for the last year or two has been a Kotlin multiplatform project. It's language interpreter that runs on the JVM, Native and Javascript. Since the project is an interpreter, it's easy to do performance testing between the different platforms. I just write some program in my language, and run it on each implementation. The results are interesting. The JVM target is consistently 20 times faster than native. Now some of this is because memory allocations are so fast in the JVM, so if your programs does less memory allocations the difference won't be that great. However, if you compile Kotlin to native code, one has to accept that it's much slower. Another problem with native compilation is that it's quite slow. I wouldn't want to do all my development using native, but rather develop using the JVM and then compile to native for the use cases that need it. The only time I think that native would make sense is if you absolutely cannot run the JVM for some reason. One such reason would be for embedded (which would have to be ARM, since that's the only embedded architecture that's supported).
- ParanoidShroom 5y ago
  I do kotlin daily, almost exclusively including side projects. Kotlin native has been rocky personally, I'll check back in a year. Kotlin on Android is a must compared to Java, else you're a fool. Haven't seen any exceptions in the industry. Kotless is okay, works, but early days. I've seen decent backends on quarkus and kotlin. It's a fun language, the couroutine development is pretty nice. Flow is a lot easier than Rxjava.
  - bestinterest 5y ago
    Coroutine stuff worries me in Kotlin, what happens the minute Project Loom comes out? Even more fracturing of styles?
- vips7L 5y ago
  Does kotlin native have a std lib yet? Last I checked you couldn’t even read a file.
- BoxOfRain 5y ago
  I absolutely love Kotlin for backend web dev, I started using it as "Java but without the things in Java that piss me off" but the more I used its non-Java features the more I grew to love it. Sadly I've moved jobs so I'm not using it professionally any more but it powers my side project so I'm keeping my skills fresh. I'd recommend it to anyone where they'd traditionally use Java or another similar language.
smackeyacky 5y ago
Has anybody switched to mixing in Kotlin code within an existing Java Android app? I'm not a huge fan of Java but I don't know whether it will be too jarring for maintenance tasks if I have both languages as code. There is a lot of XML floating around in my app (as most Android apps have) but switching between editing that and the Java is fine. I'm keen on the idea that there would be less code and my app is getting a little creaky and could use a refresh, but does Kotlin make the boring stuff easier? Things like inflating classes from REST json calls, interacting with the SQLite database. How does it do on the more "exciting" (ahem) parts of Android like Bluetooth? I lean heavily on RxAndroidBLE to cope with the rubbish bluetooth stack and I think the code around that could do with being simplified.
- pjmlp 5y ago
  On Android, it is kind of clear, Google is doubling down on Kotlin and the team is hardly motivated to move Android Java into proper Java, so long term Kotlin seems to be the only path forward. Still cherry picking features from Java 11 when Java 17 just got released, https://android-review.googlesource.com/q/project:platform%252Flibcore+status:open https://android-review.googlesource.com/q/project:platform%2...
  - smackeyacky 5y ago
    Oh really? Is this still a hangover from the Oracle lawsuit stuff? I might give it a whirl and start replacing the easy stuff first. In my system the worst part is the Android app and anything that makes it easier to maintain in the long term is welcome. edit: Not sure how I missed this announcement: https://www.zdnet.com/article/google-were-using-kotlin-programming-language-to-squash-the-bugs-that-cause-most-crashes/ https://www.zdnet.com/article/google-were-using-kotlin-progr...
    - pjmlp 5y ago
      Oracle has nothing to do with it, given that Kotlin and Android Studio are fully dependent on the JVM ecosystem. If that was the reason Dart would have been a better option, but I bet the Android team is not that keen on having Fuchsia take away their party, hence JetPack Composer.
dehrmann 5y ago
I tried Kotlin, but I went back to Java. Interacting with Java libraries can be OK, but it can also get ugly. Using companion classes for loggers seems overkill. I didn't like having to explicitly cast ints to longs. I ended up going back because Java's getting better--var and records help with some of the pain--the tooling is simpler and more reliable, and working with something like Hadoop was significantly harder.
- bberrry 5y ago
  Why would you use companion objects for loggers? The logging library should only create one instance when you do getLogger({name or class}).
travisgriggs 5y ago
I do a bit of Kotlin on Android. Two decent sized native apps. We do no Java, but use some Java libraries. I like Kotlin enough. But I don’t love it. Like Swift (and maybe Python yet), it’s a language that tacks on more stuff every release in interest of grabbing yet another programming model niche. It’s like a Swiss Army knife with a _lot_ of blades and gadgets and tools. It’s like a VC funded start up that throws features at the wall to see what sticks and placates. I want my languages to be built on simple unifying principles. Kotlin’s principles often seem to be: - we get rid of boilerplate . . . when ever we can, but not really consistently. Removing boiler plate trumps consistency in code communication - you have a rising idea over there in your ecosystem? we will add it in ours - by keeping our documentation very simple (nee spartan), we can claim our language is simple This year it is coroutines, tomorrow it will be sealed classes, or who knows.
davidatbu 5y ago
My biggest gripe with Kotlin is ... it's raison d'etre, that it's designed to incentivize me to use IntelliJ, and IntelliJ support for Kotlin is currently miles ahead of the more open alternatives. I really wanna keep using neovim and LSPs ...

93 points by minnca 5y ago

Kotlin is a really nice language. I wish it was used more especially that now it isn't just limited to the Android and Java ecosystems. Kotlin can now compile to native binaries : https://kotlinlang.org/docs/native-overview.html#sharing-code-between-platforms https://kotlinlang.org/docs/native-overview.html#sharing-cod... Kotlin can now compile to Javascript : https://kotlinlang.org/docs/js-overview.html https://kotlinlang.org/docs/js-overview.html Edit : You can even use React with Kotlin : https://kotlinlang.org/docs/js-get-started.html https://kotlinlang.org/docs/js-get-started.html Kotlin can now be used for datascience as well (You can run kotlin code in a jupyter notebook) : https://kotlinlang.org/docs/data-science-overview.html#libraries https://kotlinlang.org/docs/data-science-overview.html#libra...

pjmlp 5y ago
Kotlin/Native is hardly a stable target, given that they botched the implementation by going with an incompatible memory model as Java, and have spent the last year fixing it by rebooting it with a proper GC implementation. Hardly any better than just using GraalVM or any other JVM AOT compiler, some of which go back to early 2000's even if only available in commercial JDKs. The JavaScript compilation target still needs to do some catching up with TypeScript.
- nassimsoftware 5y ago
  What catching up is required compared to TypeScript? Could you go in bit more details on that, I'm curious.
  - pjmlp 5y ago
    Ecosystem, tooling, libraries.
    - smallerfish 5y ago
      It's actually very good - debugging from the IDE now even works. I'd recommend building around KVision rather than raw KotlinJs (https://kvision.gitbook.io/kvision-guide/ https://kvision.gitbook.io/kvision-guide/). The main thing that can be annoying is figuring out module exports from a js library that you want to use (which is probably easy enough if you have a modern javascript background). I haven't found a library that's stumped me yet, but some are more annoying than others. Jetbrains have a tool called Dukat which will supposedly one day automate this, but for now it's not there. Distribution size can be an issue, but it's not terrible. My current (moderately complex) app is floating at around 2MB. I haven't tried splitting it up, though that is possible.
      - pjmlp 5y ago
        Except the platform is JavaScript, and TypeScript is basically Web IDL aware compiler on steroids, no need to use anything that adds even more layers.
        smallerfish 5y ago
        That depends. If the rest of your application is in Kotlin, you're reducing cognitive overhead. Same language, same compile, same distribution. You can share view models between frontend and backend. It's much closer to what GWT promised to be than GWT ever was.
        pjmlp 5y ago
        Guest languages are always an impedance mismatch with the underlying platform. I don't buy into sharing source files instead of clean separation via Web APIs, the additional tooling complexity isn't worth the pain. I did vote against stuff like GWT already several times, and every time it has been proven to have been the right decision, when things went hot.
        smallerfish 5y ago
- erpellan 5y ago
  I feel the non-JVM targets are a real distraction from what is a lovely language. I’d rather they focussed more on fixing the issues with kotlin in IntelliJ - you’d think controlling both the language and the IDE would result in a less buggy experience than the current situation.
  - pjmlp 5y ago
    I agree, to me it feels just like JetBrains turned Borland just before the Inprise Corporation makeover.
  - zorr 5y ago
    Could you elaborate on specific issues you have with Kotlin/IntelliJ? I use both as my daily work environment and I barely have issues.
    - erpellan 5y ago
      It frequently loses track of libraries, claiming large chunks of the codebase won’t compile until caches are cleared and it is restarted. It gets stuck indexing forever, losing all code completion and navigation abilities until it’s restarted. Git integration sometimes stops working. It will list the files to be committed but does nothing when you click commit, until it’s restarted. Exiting presentation mode leaves the font set to a huge size (until it’s restarted).
- lokedhs 5y ago
  My personal open source evening hacking project for the last year or two has been a Kotlin multiplatform project. It's language interpreter that runs on the JVM, Native and Javascript. Since the project is an interpreter, it's easy to do performance testing between the different platforms. I just write some program in my language, and run it on each implementation. The results are interesting. The JVM target is consistently 20 times faster than native. Now some of this is because memory allocations are so fast in the JVM, so if your programs does less memory allocations the difference won't be that great. However, if you compile Kotlin to native code, one has to accept that it's much slower. Another problem with native compilation is that it's quite slow. I wouldn't want to do all my development using native, but rather develop using the JVM and then compile to native for the use cases that need it. The only time I think that native would make sense is if you absolutely cannot run the JVM for some reason. One such reason would be for embedded (which would have to be ARM, since that's the only embedded architecture that's supported).
ParanoidShroom 5y ago
I do kotlin daily, almost exclusively including side projects. Kotlin native has been rocky personally, I'll check back in a year. Kotlin on Android is a must compared to Java, else you're a fool. Haven't seen any exceptions in the industry. Kotless is okay, works, but early days. I've seen decent backends on quarkus and kotlin. It's a fun language, the couroutine development is pretty nice. Flow is a lot easier than Rxjava.
- bestinterest 5y ago
  Coroutine stuff worries me in Kotlin, what happens the minute Project Loom comes out? Even more fracturing of styles?
vips7L 5y ago
Does kotlin native have a std lib yet? Last I checked you couldn’t even read a file.
BoxOfRain 5y ago
I absolutely love Kotlin for backend web dev, I started using it as "Java but without the things in Java that piss me off" but the more I used its non-Java features the more I grew to love it. Sadly I've moved jobs so I'm not using it professionally any more but it powers my side project so I'm keeping my skills fresh. I'd recommend it to anyone where they'd traditionally use Java or another similar language.

smackeyacky 5y ago

Has anybody switched to mixing in Kotlin code within an existing Java Android app? I'm not a huge fan of Java but I don't know whether it will be too jarring for maintenance tasks if I have both languages as code. There is a lot of XML floating around in my app (as most Android apps have) but switching between editing that and the Java is fine. I'm keen on the idea that there would be less code and my app is getting a little creaky and could use a refresh, but does Kotlin make the boring stuff easier? Things like inflating classes from REST json calls, interacting with the SQLite database. How does it do on the more "exciting" (ahem) parts of Android like Bluetooth? I lean heavily on RxAndroidBLE to cope with the rubbish bluetooth stack and I think the code around that could do with being simplified.

pjmlp 5y ago
On Android, it is kind of clear, Google is doubling down on Kotlin and the team is hardly motivated to move Android Java into proper Java, so long term Kotlin seems to be the only path forward. Still cherry picking features from Java 11 when Java 17 just got released, https://android-review.googlesource.com/q/project:platform%252Flibcore+status:open https://android-review.googlesource.com/q/project:platform%2...
- smackeyacky 5y ago
  Oh really? Is this still a hangover from the Oracle lawsuit stuff? I might give it a whirl and start replacing the easy stuff first. In my system the worst part is the Android app and anything that makes it easier to maintain in the long term is welcome. edit: Not sure how I missed this announcement: https://www.zdnet.com/article/google-were-using-kotlin-programming-language-to-squash-the-bugs-that-cause-most-crashes/ https://www.zdnet.com/article/google-were-using-kotlin-progr...
  - pjmlp 5y ago
    Oracle has nothing to do with it, given that Kotlin and Android Studio are fully dependent on the JVM ecosystem. If that was the reason Dart would have been a better option, but I bet the Android team is not that keen on having Fuchsia take away their party, hence JetPack Composer.

dehrmann 5y ago

I tried Kotlin, but I went back to Java. Interacting with Java libraries can be OK, but it can also get ugly. Using companion classes for loggers seems overkill. I didn't like having to explicitly cast ints to longs. I ended up going back because Java's getting better--var and records help with some of the pain--the tooling is simpler and more reliable, and working with something like Hadoop was significantly harder.

bberrry 5y ago
Why would you use companion objects for loggers? The logging library should only create one instance when you do getLogger({name or class}).

travisgriggs 5y ago

I do a bit of Kotlin on Android. Two decent sized native apps. We do no Java, but use some Java libraries. I like Kotlin enough. But I don’t love it. Like Swift (and maybe Python yet), it’s a language that tacks on more stuff every release in interest of grabbing yet another programming model niche. It’s like a Swiss Army knife with a _lot_ of blades and gadgets and tools. It’s like a VC funded start up that throws features at the wall to see what sticks and placates. I want my languages to be built on simple unifying principles. Kotlin’s principles often seem to be: - we get rid of boilerplate . . . when ever we can, but not really consistently. Removing boiler plate trumps consistency in code communication - you have a rising idea over there in your ecosystem? we will add it in ours - by keeping our documentation very simple (nee spartan), we can claim our language is simple This year it is coroutines, tomorrow it will be sealed classes, or who knows.

davidatbu 5y ago

My biggest gripe with Kotlin is ... it's raison d'etre, that it's designed to incentivize me to use IntelliJ, and IntelliJ support for Kotlin is currently miles ahead of the more open alternatives. I really wanna keep using neovim and LSPs ...