10 ms·

I really want to try Kotlin out. I want to give it a chance. The problem is that I can't help but feel it will become abandonware in the future. Somebody will b

I really want to try Kotlin out. I want to give it a chance. The problem is that I can't help but feel it will become abandonware in the future. Somebody will buy JetBrains or they will start cutting costs and then Kotlin will be no more. Am I being unreasonable here? As an aside, I've felt that same "love" feeling with Scala, Clojure, and Nim. It's a great feeling because you start to imagine what can be.

sago 10y ago
I don't think you're being unreasonable. In my experimentation I concluded that Kotlin was largely chasing a subset mindshare of Scala, so I see it being at a long term disadvantage. That said, one killer app can make a language, so who knows. But if you want a typed expressive hybrid-paradigm JVM language, it seems Scala is the obvious choice.
- pjmlp 10y ago
  I agree with you, however currently JetBrains is making sure Kotlin works reasonable well on Android, while no one really cares about Scala on Android. Yes many in the Scala community do care, but there isn't an ongoing effort with Android Studio tooling integration as in Kotlin. So this could be a way for it to pick up steam, but it remains to be seen if the Android team still keeps the "We care only about Java" attitude at the upcoming Google IO.
  - sago 10y ago
    Good point, and one I've got a blindspot for because we're not coding for Android (other than via Unity). So yes, that could be enough of the 'killer app', if Android stays with Java. Do you have any intuition for why 'nobody cares about Scala on Android'? Not doubting you, just curious.
    - pjmlp 10y ago
      I doubt they would move away from Java, in spite of the ongoing trial. The question is officially supporting other JVM languages. There are some people writing sbt plugins for Android development, but that is not the same as the full Android Studio development experience.
  - airless_bar 10y ago
    Android integration works fine, and the SBT builder is so much better and faster than Google's Gradle one. In fact SBT + ProGuard is faster than Gradle + no ProGuard.
    - pjmlp 10y ago
      Last time I looked into it, it didn't seem to integrate that well with Android Studio and all the GUI tools. Has this somehow improved?
      - airless_bar 10y ago
        Which GUI tools do you have in mind?
        pjmlp 10y ago
        Android studio and everything that depends on the Gradle integration deep within it. For example, I do actually like XML, but when I looked at it I came out with the idea that I could not use the visual tooling any longer, rather some Scala DSL.
        airless_bar 10y ago
        Ah alright. yes, I think it makes more sense to define the GUI with code. Typed resources help with it. sbt-android-gradle has full support for Gradle projects, but to be honest: Gradle is utter shit. Just use the SBT plugin. it works so much better. The latest version even manages SDK and NDK for you.
        pjmlp 10y ago
        I agree with your opinion, if it wasn't for Android I very much doubt anyone would care about Gradle. Have to try it out again.
        vorg 10y ago
        I don't like having to use a different language (i.e. Apache Groovy) to write build scripts when using Gradle with Scala. With SBT, I write Scala to build Scala, see [1]. I can see why someone would use Groovy to build a Groovy project, but why should I use 20 lines of Groovy to build Scala? I notice Kobalt [2] for Kotlin is still being actively developed, and Leiningen for Clojure, both using the syntax of the language they're compiling for their build DSL. If Gradle won't become language agnostic for specifying its build scripts instead of shoving something else down people's throats, people will elsewhere, or stick with Maven. [1] http://alvinalexander.com/scala/sbt-syntax-examples http://alvinalexander.com/scala/sbt-syntax-examples [2] https://github.com/cbeust/kobalt https://github.com/cbeust/kobalt
- hhariri 10y ago
  I don't believe our goal was to capture a subset of Scala developers.
  - sago 10y ago
    Not quite what I meant. I meant the set of people for whom Kotlin would be a good fit is largely (but not totally, I'd guess) a subset of those who would gain from using Scala. Therefore for any developer auditing languages, Kotlin and Scala are likely to be peers (as they were for me) and in that case, Scala being more established (i.e. more resources, more employees, more stack overflow questions) means Kotlin would struggle. I just re-read the 'comparison to Scala' page, and that seems to reinforce that, e.g.: "if you're happy with Scala, you don't need Kotlin". Which is not to argue my point: you know your goals far better than I. But if anything, take it as a gentle criticism of your messaging.
jrcii 10y ago
Is that love for Clojure past tense?
- partisan 10y ago
  I like Clojure, still.
pjmlp 10y ago
> Am I being unreasonable here? No, you are being pretty reasonable. I am programming since the mid-80's, and as a language geek I have dabbled in lots of programming languages, focusing in systems programming lectures (compilers, graphics and OS architectures) at the university. What I learned through my professional career was to only rely on OS SDK sanctioned programming languages for production code. OS vendors also discontinue their official languages, but there is a higher probability that the programming languages will stay around vs tool vendor X. The way Borland and ETHZ mismanaged their programming languages made me eventually adopt this attitude. So I tend to be a late adopter in what concerns programming languages and as such find that you are quite reasonable.
bjourne 10y ago
"try <programming language> out" means experimenting with it for a few hours. Whether it becomes abandonware in the future shouldn't affect the decision whether to do that or not.
- partisan 10y ago
  Understood. I am past the few hours mark with Kotlin. It's the commitment to building something lasting that makes me hesitate.
hhariri 10y ago
We have close to 10 products that are using Kotlin, quite a few of them entirely written in Kotlin. Most new projects we start are using Kotlin. Given we've invested 6 years into Kotlin already and are shipping products with it, I doubt it will become abandonware.
- partisan 10y ago
  Thanks for the response. It is a good counterpoint.
V-2 10y ago
While it's a reasonable concern, I don't think there's so much overhead in learning Kotlin. It's fully interoperable with Java, so you don't need to invest in learning new APIs (which is the difficult part usually). Other than that, it's really light-weight and easy to pick up, you can learn it in a matter of days. Most of its features are bits and pieces, or "the good parts", from other programming languages, quite familiar for any developer who's been around the block.

sago 10y ago

I don't think you're being unreasonable. In my experimentation I concluded that Kotlin was largely chasing a subset mindshare of Scala, so I see it being at a long term disadvantage. That said, one killer app can make a language, so who knows. But if you want a typed expressive hybrid-paradigm JVM language, it seems Scala is the obvious choice.

pjmlp 10y ago
I agree with you, however currently JetBrains is making sure Kotlin works reasonable well on Android, while no one really cares about Scala on Android. Yes many in the Scala community do care, but there isn't an ongoing effort with Android Studio tooling integration as in Kotlin. So this could be a way for it to pick up steam, but it remains to be seen if the Android team still keeps the "We care only about Java" attitude at the upcoming Google IO.
- sago 10y ago
  Good point, and one I've got a blindspot for because we're not coding for Android (other than via Unity). So yes, that could be enough of the 'killer app', if Android stays with Java. Do you have any intuition for why 'nobody cares about Scala on Android'? Not doubting you, just curious.
  - pjmlp 10y ago
    I doubt they would move away from Java, in spite of the ongoing trial. The question is officially supporting other JVM languages. There are some people writing sbt plugins for Android development, but that is not the same as the full Android Studio development experience.
- airless_bar 10y ago
  Android integration works fine, and the SBT builder is so much better and faster than Google's Gradle one. In fact SBT + ProGuard is faster than Gradle + no ProGuard.
  - pjmlp 10y ago
    Last time I looked into it, it didn't seem to integrate that well with Android Studio and all the GUI tools. Has this somehow improved?
    - airless_bar 10y ago
      Which GUI tools do you have in mind?
      - pjmlp 10y ago
        Android studio and everything that depends on the Gradle integration deep within it. For example, I do actually like XML, but when I looked at it I came out with the idea that I could not use the visual tooling any longer, rather some Scala DSL.
        airless_bar 10y ago
        Ah alright. yes, I think it makes more sense to define the GUI with code. Typed resources help with it. sbt-android-gradle has full support for Gradle projects, but to be honest: Gradle is utter shit. Just use the SBT plugin. it works so much better. The latest version even manages SDK and NDK for you.
        pjmlp 10y ago
        I agree with your opinion, if it wasn't for Android I very much doubt anyone would care about Gradle. Have to try it out again.
        vorg 10y ago
        I don't like having to use a different language (i.e. Apache Groovy) to write build scripts when using Gradle with Scala. With SBT, I write Scala to build Scala, see [1]. I can see why someone would use Groovy to build a Groovy project, but why should I use 20 lines of Groovy to build Scala? I notice Kobalt [2] for Kotlin is still being actively developed, and Leiningen for Clojure, both using the syntax of the language they're compiling for their build DSL. If Gradle won't become language agnostic for specifying its build scripts instead of shoving something else down people's throats, people will elsewhere, or stick with Maven. [1] http://alvinalexander.com/scala/sbt-syntax-examples http://alvinalexander.com/scala/sbt-syntax-examples [2] https://github.com/cbeust/kobalt https://github.com/cbeust/kobalt
hhariri 10y ago
I don't believe our goal was to capture a subset of Scala developers.
- sago 10y ago
  Not quite what I meant. I meant the set of people for whom Kotlin would be a good fit is largely (but not totally, I'd guess) a subset of those who would gain from using Scala. Therefore for any developer auditing languages, Kotlin and Scala are likely to be peers (as they were for me) and in that case, Scala being more established (i.e. more resources, more employees, more stack overflow questions) means Kotlin would struggle. I just re-read the 'comparison to Scala' page, and that seems to reinforce that, e.g.: "if you're happy with Scala, you don't need Kotlin". Which is not to argue my point: you know your goals far better than I. But if anything, take it as a gentle criticism of your messaging.

jrcii 10y ago

Is that love for Clojure past tense?

partisan 10y ago
I like Clojure, still.

pjmlp 10y ago

> Am I being unreasonable here? No, you are being pretty reasonable. I am programming since the mid-80's, and as a language geek I have dabbled in lots of programming languages, focusing in systems programming lectures (compilers, graphics and OS architectures) at the university. What I learned through my professional career was to only rely on OS SDK sanctioned programming languages for production code. OS vendors also discontinue their official languages, but there is a higher probability that the programming languages will stay around vs tool vendor X. The way Borland and ETHZ mismanaged their programming languages made me eventually adopt this attitude. So I tend to be a late adopter in what concerns programming languages and as such find that you are quite reasonable.

bjourne 10y ago

"try <programming language> out" means experimenting with it for a few hours. Whether it becomes abandonware in the future shouldn't affect the decision whether to do that or not.

partisan 10y ago
Understood. I am past the few hours mark with Kotlin. It's the commitment to building something lasting that makes me hesitate.

hhariri 10y ago

We have close to 10 products that are using Kotlin, quite a few of them entirely written in Kotlin. Most new projects we start are using Kotlin. Given we've invested 6 years into Kotlin already and are shipping products with it, I doubt it will become abandonware.

partisan 10y ago
Thanks for the response. It is a good counterpoint.

V-2 10y ago

While it's a reasonable concern, I don't think there's so much overhead in learning Kotlin. It's fully interoperable with Java, so you don't need to invest in learning new APIs (which is the difficult part usually). Other than that, it's really light-weight and easy to pick up, you can learn it in a matter of days. Most of its features are bits and pieces, or "the good parts", from other programming languages, quite familiar for any developer who's been around the block.