4 ms·

People usually get confused when we tell them that we're using Kotlin for our backend APIs. I can't blame them because we attended KotlinConf last year and almo

People usually get confused when we tell them that we're using Kotlin for our backend APIs. I can't blame them because we attended KotlinConf last year and almost 90% of the audience were using Kotlin on the Android platform. Hopefully, it gets more attraction from different platforms because staying in the JVM land and being able to use an expressive & lightweight language is great!

pjmlp 7y ago
Problem is that thanks to Android (stuck on partial Java 8 support), and JetBrains plans to put Kotlin everywhere as they try to build a business on top of it (Borland Turbo Pascal style), there is only so much that they can access on the JVM while making Kotlin code portable, specially regarding the Valhala, Panama and Loom roadmaps.
- rnentjes 7y ago
  There is nothing keeping them from not making some constructs not portable to certain platforms. Mostly they try to do this with standard language constructs (of course), but for example the 'dynamic' type is completely javascript specific. This only goes for Valhala. The other examples seem to be java playing catch-up to Kotlin (Panama for Kotlin native and Loom for co-routines).
  - pjmlp 7y ago
    Co-routines aren't the same as Loom, as they require explicitly code and thus might not interop cleanly with the new Loom thread semantics. Does Kotlin/Native support multi field value classes? Yes you can get around portability issues with multiple platform Kotlin, as many other guest languages have tried to. However then one begs the question why use the language at all, when having to write the same stuff multiple times. I rather have the JVM, .NET take the OS decision away, not see them as yet another OS to deploy on.
    - rnentjes 7y ago
      Yes, the upside of one language should be that you don't have to write the same stuff multiple times. But if you don't want the downside of having one common denominator holding you back, then you have to write some parts specifically for each platform. That is the option Kotlin gives you. And my point was that this doesn't necessarily mean it will hold the specific platforms back (which seemed to be your point).
edem 7y ago
I have been using Kotlin on the backend for 4 years. I never used it on Android!
jillesvangurp 7y ago
Sebastian Deleuze who is one of the Kotlin people working on Spring just gave a presentation of the status of Kotlin support in Spring: https://www.infoq.com/presentations/spring-kotlin-boot-kofu/ https://www.infoq.com/presentations/spring-kotlin-boot-kofu/. In short, if you are using Spring and are ignoring Kotlin, you are missing out a lot of good stuff. Or in other words, the same that happened to Java on Android is now happening to backend Java. You can still use it but why would you when things can be so much better with a simple upgrade to Kotlin (I've migrated tens of thousands of lines of code, it's easy). And yes Java 9-14 added a bunch of things that are definitely nice/useful but it doesn't come close to Kotlin in terms of expressiveness and language ergonomics. Also, KotlinConf was on last week. There was a nice presentation about the state of kotlin-js, which is getting some nice updates in the next year including much better dead code elimination resulting in very compact minified code (< 100kb is now feasible for simple stuff), better integration of existing typescript type script defifinitions (i.e. support for most relevant npms out there), better build tooling in the form of an improved gradle plugin. Or put different, Kotlin might start doing to typescript/javascript what it already did to Java. IMHO it's a more capable language than typescript, which I consider to be pretty nice but it just lacks a bunch of things and comes with a some ugliness that relates to backwards compatibility with js. In related news, Kotlin native is also happening. So, Kotlin is joining a list of full stack languages that used to be really short.
- buremba 7y ago
  I tried using Spring with Kotlin last year but it felt verbose as if I'm writing Java so we decided to implement support for Kotlin in our in-house Netty-based server (https://github.com/buremba/netty-rest https://github.com/buremba/netty-rest) and use it. Great to hear that Spring finally has native integration with Kotlin!
- jeremija 7y ago
  What's the status of Kotlin Native for writing backend apps? I really like it but I wouldn't want to get dragged into Gradle, JARs and JDBC again...
  - 7y ago
dopamean 7y ago
I the company I've been working at in Austin and we've been increasingly choosing Kotlin for our backend services as well. We started with Scala and found the ramp up to be tough. I came from a company that used mostly Ruby before and had no JVM experience at all and I found kotlin really easy to get productive with in a short amount of time. I actually prefer it in many ways not to everything else I had done before (I think I just really like static typing).
- tuxman 7y ago
  I'm curious to know what difficulties you found using Scala and your experiences transitioning to Kotlin, if you are willing to expound upon it.
gameswithgo 7y ago
That's interesting. I'd be more inclined to use Rust/C++ for the android devices since they are slow and more inclined to use Kotlin on the server because they are powerful :D

pjmlp 7y ago

Problem is that thanks to Android (stuck on partial Java 8 support), and JetBrains plans to put Kotlin everywhere as they try to build a business on top of it (Borland Turbo Pascal style), there is only so much that they can access on the JVM while making Kotlin code portable, specially regarding the Valhala, Panama and Loom roadmaps.

rnentjes 7y ago
There is nothing keeping them from not making some constructs not portable to certain platforms. Mostly they try to do this with standard language constructs (of course), but for example the 'dynamic' type is completely javascript specific. This only goes for Valhala. The other examples seem to be java playing catch-up to Kotlin (Panama for Kotlin native and Loom for co-routines).
- pjmlp 7y ago
  Co-routines aren't the same as Loom, as they require explicitly code and thus might not interop cleanly with the new Loom thread semantics. Does Kotlin/Native support multi field value classes? Yes you can get around portability issues with multiple platform Kotlin, as many other guest languages have tried to. However then one begs the question why use the language at all, when having to write the same stuff multiple times. I rather have the JVM, .NET take the OS decision away, not see them as yet another OS to deploy on.
  - rnentjes 7y ago
    Yes, the upside of one language should be that you don't have to write the same stuff multiple times. But if you don't want the downside of having one common denominator holding you back, then you have to write some parts specifically for each platform. That is the option Kotlin gives you. And my point was that this doesn't necessarily mean it will hold the specific platforms back (which seemed to be your point).

edem 7y ago

I have been using Kotlin on the backend for 4 years. I never used it on Android!

jillesvangurp 7y ago

Sebastian Deleuze who is one of the Kotlin people working on Spring just gave a presentation of the status of Kotlin support in Spring: https://www.infoq.com/presentations/spring-kotlin-boot-kofu/ https://www.infoq.com/presentations/spring-kotlin-boot-kofu/. In short, if you are using Spring and are ignoring Kotlin, you are missing out a lot of good stuff. Or in other words, the same that happened to Java on Android is now happening to backend Java. You can still use it but why would you when things can be so much better with a simple upgrade to Kotlin (I've migrated tens of thousands of lines of code, it's easy). And yes Java 9-14 added a bunch of things that are definitely nice/useful but it doesn't come close to Kotlin in terms of expressiveness and language ergonomics. Also, KotlinConf was on last week. There was a nice presentation about the state of kotlin-js, which is getting some nice updates in the next year including much better dead code elimination resulting in very compact minified code (< 100kb is now feasible for simple stuff), better integration of existing typescript type script defifinitions (i.e. support for most relevant npms out there), better build tooling in the form of an improved gradle plugin. Or put different, Kotlin might start doing to typescript/javascript what it already did to Java. IMHO it's a more capable language than typescript, which I consider to be pretty nice but it just lacks a bunch of things and comes with a some ugliness that relates to backwards compatibility with js. In related news, Kotlin native is also happening. So, Kotlin is joining a list of full stack languages that used to be really short.

buremba 7y ago
I tried using Spring with Kotlin last year but it felt verbose as if I'm writing Java so we decided to implement support for Kotlin in our in-house Netty-based server (https://github.com/buremba/netty-rest https://github.com/buremba/netty-rest) and use it. Great to hear that Spring finally has native integration with Kotlin!
jeremija 7y ago
What's the status of Kotlin Native for writing backend apps? I really like it but I wouldn't want to get dragged into Gradle, JARs and JDBC again...
- 7y ago

dopamean 7y ago

I the company I've been working at in Austin and we've been increasingly choosing Kotlin for our backend services as well. We started with Scala and found the ramp up to be tough. I came from a company that used mostly Ruby before and had no JVM experience at all and I found kotlin really easy to get productive with in a short amount of time. I actually prefer it in many ways not to everything else I had done before (I think I just really like static typing).

tuxman 7y ago
I'm curious to know what difficulties you found using Scala and your experiences transitioning to Kotlin, if you are willing to expound upon it.

gameswithgo 7y ago

That's interesting. I'd be more inclined to use Rust/C++ for the android devices since they are slow and more inclined to use Kotlin on the server because they are powerful :D