7 ms·

I feel kotlin is a bit undervalue. It is a great modern language which can replace java completely. Along with swift, they should be the general purpose progra

by jorgemf 10y ago

I feel kotlin is a bit undervalue. It is a great modern language which can replace java completely. Along with swift, they should be the general purpose programming languages in the near future.

chinhodado 10y ago
> Along with swift, they should be the general purpose programming languages in the near future. Unfortunately that is not going to happen for Kotlin, unless it gets adopted by major projects, and by major I mean on the scale of Android. Java is not going anywhere soon. If anything, Kotlin will become a second Scala.
- jorgemf 10y ago
  Well, it is broadly used by Android developers. For me Kotlin is above scala just because the tooling support (JetBrains the main developers of kotlin), and I find a big difference when writting kotlin and scala. I feel scala more difficult to read, while kotlin is just a pleasure to read code. Moreover you can mix java and kotlin in the same project without issues. Why do you think it will be behind scala?
  - chinhodado 10y ago
    I don't mean to say it will be behind Scala, I just mean to say that it will end up in the same situation as Scala, a language that was meant to be a "better Java" but could never gain enough traction to take off.
    - jorgemf 10y ago
      When I used Scala I never though it would be better than java, just another alternative. But I think kotlin is better than java. I hope it gains traction but not sure about it.
- relics443 10y ago
  Kotlin has a much smaller learning curve than Scala. I find it to be much more useful than any other language I've tried out. It has shiny, useful features like some of the more dynamic languages do, but it's close enough to Java that I'm comfortable using it.
  - parasubcutaneor 10y ago
    Without having tried Kotlin myself, is it in any way compable to Groovy? Are there any benefits or tradeoffs, based on what you might know about Groovy?
    - mike_hearn 10y ago
      Kotlin's design was heavily influenced by Groovy. You can see it in the builder DSLs, the syntax, the fact that Gradle is adding support for Kotlin alongside Gradle, and comments by the Kotlin designers. The big difference of course is that Gradle is dynamically typed by default.
      - vorg 10y ago
        > Gradle is adding support for Kotlin alongside Gradle, and comments by the Kotlin designers. The big difference of course is that Gradle is dynamically typed by default. You've fallen for the trap of mistaking Gradle to be Apache Groovy, perhaps because those 10-line build scripts for Gradle are the only encounter most programmers have with Groovy. Your comment should read "Gradle is adding support for Kotlin alongside Groovy, and comments by the Kotlin designers. The big difference of course is that Groovy is dynamically typed by default."
        mike_hearn 10y ago
        You're right - I know the difference but apparently something got corrupted between brain and keyboard!
    - relics443 10y ago
      It's similar to Groovy, which I've worked with non extensively, but I think it adds a lot more. I've always found development in Groovy to be closer to Ruby or Python, while Kotlin feels more like Java (just better :-)
kirillkh 10y ago
Kotlin is one fine piece of engineering. It's only too unfortunate that the same Achilles' heel is holding it back as Scala: there is only so much you can do while remaining compatible with JVM and the Java standard library. Actually, it's even worse: Kotlin swore a seamless compatibility with Java. Maintaining compatibility against a moving target has the potential to make things quite messy. An early example of that presented itself just after Kotlin 1.0 release, when Java 8 came out with with new and shiny functional Collections API - incompatible to Kotlin's.
- jorgemf 10y ago
  The new Collections API wasn't incompatible with kotlin, it is just you can use the new API if you target Java 6 (which makes sense). But you can use the new API if you target Java 8. So I don't see a big deal here. The problem is not the compatibility with the new Java API, but with the new bytecode definition. But it is going to have the same problems Java have. The big difference with Java here is that you can adopt new bytecode specifications without using the new Java APIs, or doing some modification in the bytecode generation to "simulate" those new features. And this is the key why it is taking over Android community. You can support legacy bytecode with new features. Which you cannot do with Java. A problem for kotlin (and java) is the new packaging system. But kotlin is already working on it changing how they package their standard library. So it is even less problem than java.
  - kirillkh 10y ago
    > The new Collections API wasn't incompatible with kotlin There definitely is a problem, as can be seen e.g. here: https://discuss.kotlinlang.org/t/jdk-8-compatibility-of-kotlin/73/6 https://discuss.kotlinlang.org/t/jdk-8-compatibility-of-kotl... Quoting: "Sometime ago we introduced kotlin.Stream<T> type, with the simples possible interface – iterator() function – with the idea that we can make it compatible with Java8 Stream<T> type. Currently we seem to come to a conclusion it was a mistake as we cannot fine a way to represent Stream<T> as kotlin type in Java 6 & 7, and then use to Java8's Stream<T> when targeting JDK8. If you have any idea about how to make it work – please share!" Basically, while Kotlin is more or less a straightforward extension of the Java 6'th Collections APIs, by Java 8's release the two have diverged. When programming in Kotlin, you would normally use its own functional APIs, not Java Streams API. While technically nothing prevents you from using Streams, they don't fully integrate with Kotlin's native Collections, so you're forced to choose one or another.
crispinb 10y ago
This is one of those cases where it doesn't matter that much. World domination is overrated. The JVM's prevalence largely takes care of platform availability. Java interop ensures enough libraries will continue to be available for use. And Jetbrains' internal use of kotlin on a large codebase ensures the language's sustainability. What more is needed?
- jorgemf 10y ago
  I would want to see a bigger adoption and companies start using it more often, so I can use it in more projects. I really like using it over other languages. Every time I write java I think: I would had spent less time writing this in kotlin and the code would be more readable. Every time I use a non-statically typed language and have a bug because of it I drop a tear thinking that I would never had that bug that took me a couple of days to find in kotlin.
  - crispinb 10y ago
    Oh sure it would be nice to see it adopted more widely. I just mean it's not in the vulnerable position of most new(ish) languages. Kotlin is ready for use in any suitable project by anyone who likes it. Though I'm a bit raw with it as yet, I love it for Android. Look forward to seeing the javascript & native possibilities.
  - cel1ne 10y ago
    Why not use it on a file-to-file basis in a Java-project. That is exactly what the makers thought of.
    - jorgemf 10y ago
      Because sometimes you have to use other language and other times you have a boss which takes the decisions. All my side projects are kotlin now.
agumonkey 10y ago
I find the compiler a "tad" slow, just a tad, I don't know if it's a matter of prioritization or semantics. If the thing was javac-ish, I'd probably make it a daily driver.
- jorgemf 10y ago
  Completely agree with you, and I wouldn't expect it to be faster than javac as it needs more semantic processing. (some pleople find it faster: https://medium.com/keepsafe-engineering/kotlin-vs-java-compilation-speed-e6c174b39b5d#.pojv5uakx https://medium.com/keepsafe-engineering/kotlin-vs-java-compi... ) What I think it is slower right now are the tools. Sometimes IdeaJ stucks. I guess they will be improving the performance slowly as right now they are other things in the language more important to focus.
  - vbezhenar 10y ago
    Jetbrains uses Kotlin for their own projects, including Intellij Idea. So you can be sure, that its support will be reasonably good, they use it themselves after all.
lmm 10y ago
> I feel kotlin is a bit undervalue. It is a great modern language which can replace java completely. It doesn't offer a compelling advantage. "Slightly cleaned-up Java with a bit of syntax sugar" is not enough to justify having to make all your tooling (IDEs, profilers, monitoring, code coverage ...) support a new language. And if you are going to make all that effort, why would you not pick a language that offers some genuine killer features in return, like Scala or Ceylon? And it's got a lot of special cases, a lot of stuff in the language that should just be libraries, that I think will make it hard to maintain in the long run (the "CoffeeScript of Java" line is probably fair). If anything it seems overhyped to me.
- marc_omorain 10y ago
  > "Slightly cleaned-up Java with a bit of syntax sugar" This is not an accurate description of Kotlin. Kotlin has many features that make it better than Java. Most importantly, it is null-safe. In addition to that it makes it simple to enforce data-immutability, which is very difficult in Java. https://kotlinlang.org/docs/reference/comparison-to-java.html https://kotlinlang.org/docs/reference/comparison-to-java.htm...
  - lmm 10y ago
    > Kotlin has many features that make it better than Java. Most importantly, it is null-safe. In addition to that it makes it simple to enforce data-immutability, which is very difficult in Java. Kotlin does have nullability handling yes, but it's a very limited special-case feature - it's a language-level builtin rather than something you can use in your own libraries. E.g. if you want to have an error message in the failure case rather than just null (i.e. some kind of Result type), you can't reuse any of the null-safety functionality (whereas in Scala or Ceylon you can write the same methods to work with either optional/nullable or result-like types). Data immutability isn't at all difficult in Java. It's tedious (sprinkling "final" everywhere), but not hard.
    - hota_mazi 10y ago
      > it's a language-level builtin rather than something you can use in your own libraries The only people who still think that a library approach is superior to a compiler approach are Scala users. I'll clarify this for you: if it's a library construct, it can be ignored. And as a matter of fact, there is nothing in Scala forcing you to use `Option`. You can completely ignore it and enjoy your time diagnosing NullPointerExceptions everywhere. When a feature is enforced by the compiler, such as Kotlin and Ceylon, you don't get any easy way out: you have to think about null cases or you will not be able to compile your code. Period.

by jorgemf 10y ago

I feel kotlin is a bit undervalue. It is a great modern language which can replace java completely. Along with swift, they should be the general purpose programming languages in the near future.

chinhodado 10y ago

> Along with swift, they should be the general purpose programming languages in the near future. Unfortunately that is not going to happen for Kotlin, unless it gets adopted by major projects, and by major I mean on the scale of Android. Java is not going anywhere soon. If anything, Kotlin will become a second Scala.

jorgemf 10y ago
Well, it is broadly used by Android developers. For me Kotlin is above scala just because the tooling support (JetBrains the main developers of kotlin), and I find a big difference when writting kotlin and scala. I feel scala more difficult to read, while kotlin is just a pleasure to read code. Moreover you can mix java and kotlin in the same project without issues. Why do you think it will be behind scala?
- chinhodado 10y ago
  I don't mean to say it will be behind Scala, I just mean to say that it will end up in the same situation as Scala, a language that was meant to be a "better Java" but could never gain enough traction to take off.
  - jorgemf 10y ago
    When I used Scala I never though it would be better than java, just another alternative. But I think kotlin is better than java. I hope it gains traction but not sure about it.
relics443 10y ago
Kotlin has a much smaller learning curve than Scala. I find it to be much more useful than any other language I've tried out. It has shiny, useful features like some of the more dynamic languages do, but it's close enough to Java that I'm comfortable using it.
- parasubcutaneor 10y ago
  Without having tried Kotlin myself, is it in any way compable to Groovy? Are there any benefits or tradeoffs, based on what you might know about Groovy?
  - mike_hearn 10y ago
    Kotlin's design was heavily influenced by Groovy. You can see it in the builder DSLs, the syntax, the fact that Gradle is adding support for Kotlin alongside Gradle, and comments by the Kotlin designers. The big difference of course is that Gradle is dynamically typed by default.
    - vorg 10y ago
      > Gradle is adding support for Kotlin alongside Gradle, and comments by the Kotlin designers. The big difference of course is that Gradle is dynamically typed by default. You've fallen for the trap of mistaking Gradle to be Apache Groovy, perhaps because those 10-line build scripts for Gradle are the only encounter most programmers have with Groovy. Your comment should read "Gradle is adding support for Kotlin alongside Groovy, and comments by the Kotlin designers. The big difference of course is that Groovy is dynamically typed by default."
      - mike_hearn 10y ago
        You're right - I know the difference but apparently something got corrupted between brain and keyboard!
  - relics443 10y ago
    It's similar to Groovy, which I've worked with non extensively, but I think it adds a lot more. I've always found development in Groovy to be closer to Ruby or Python, while Kotlin feels more like Java (just better :-)

kirillkh 10y ago

Kotlin is one fine piece of engineering. It's only too unfortunate that the same Achilles' heel is holding it back as Scala: there is only so much you can do while remaining compatible with JVM and the Java standard library. Actually, it's even worse: Kotlin swore a seamless compatibility with Java. Maintaining compatibility against a moving target has the potential to make things quite messy. An early example of that presented itself just after Kotlin 1.0 release, when Java 8 came out with with new and shiny functional Collections API - incompatible to Kotlin's.

jorgemf 10y ago
The new Collections API wasn't incompatible with kotlin, it is just you can use the new API if you target Java 6 (which makes sense). But you can use the new API if you target Java 8. So I don't see a big deal here. The problem is not the compatibility with the new Java API, but with the new bytecode definition. But it is going to have the same problems Java have. The big difference with Java here is that you can adopt new bytecode specifications without using the new Java APIs, or doing some modification in the bytecode generation to "simulate" those new features. And this is the key why it is taking over Android community. You can support legacy bytecode with new features. Which you cannot do with Java. A problem for kotlin (and java) is the new packaging system. But kotlin is already working on it changing how they package their standard library. So it is even less problem than java.
- kirillkh 10y ago
  > The new Collections API wasn't incompatible with kotlin There definitely is a problem, as can be seen e.g. here: https://discuss.kotlinlang.org/t/jdk-8-compatibility-of-kotlin/73/6 https://discuss.kotlinlang.org/t/jdk-8-compatibility-of-kotl... Quoting: "Sometime ago we introduced kotlin.Stream<T> type, with the simples possible interface – iterator() function – with the idea that we can make it compatible with Java8 Stream<T> type. Currently we seem to come to a conclusion it was a mistake as we cannot fine a way to represent Stream<T> as kotlin type in Java 6 & 7, and then use to Java8's Stream<T> when targeting JDK8. If you have any idea about how to make it work – please share!" Basically, while Kotlin is more or less a straightforward extension of the Java 6'th Collections APIs, by Java 8's release the two have diverged. When programming in Kotlin, you would normally use its own functional APIs, not Java Streams API. While technically nothing prevents you from using Streams, they don't fully integrate with Kotlin's native Collections, so you're forced to choose one or another.

crispinb 10y ago

This is one of those cases where it doesn't matter that much. World domination is overrated. The JVM's prevalence largely takes care of platform availability. Java interop ensures enough libraries will continue to be available for use. And Jetbrains' internal use of kotlin on a large codebase ensures the language's sustainability. What more is needed?

jorgemf 10y ago
I would want to see a bigger adoption and companies start using it more often, so I can use it in more projects. I really like using it over other languages. Every time I write java I think: I would had spent less time writing this in kotlin and the code would be more readable. Every time I use a non-statically typed language and have a bug because of it I drop a tear thinking that I would never had that bug that took me a couple of days to find in kotlin.
- crispinb 10y ago
  Oh sure it would be nice to see it adopted more widely. I just mean it's not in the vulnerable position of most new(ish) languages. Kotlin is ready for use in any suitable project by anyone who likes it. Though I'm a bit raw with it as yet, I love it for Android. Look forward to seeing the javascript & native possibilities.
- cel1ne 10y ago
  Why not use it on a file-to-file basis in a Java-project. That is exactly what the makers thought of.
  - jorgemf 10y ago
    Because sometimes you have to use other language and other times you have a boss which takes the decisions. All my side projects are kotlin now.

agumonkey 10y ago

I find the compiler a "tad" slow, just a tad, I don't know if it's a matter of prioritization or semantics. If the thing was javac-ish, I'd probably make it a daily driver.

jorgemf 10y ago
Completely agree with you, and I wouldn't expect it to be faster than javac as it needs more semantic processing. (some pleople find it faster: https://medium.com/keepsafe-engineering/kotlin-vs-java-compilation-speed-e6c174b39b5d#.pojv5uakx https://medium.com/keepsafe-engineering/kotlin-vs-java-compi... ) What I think it is slower right now are the tools. Sometimes IdeaJ stucks. I guess they will be improving the performance slowly as right now they are other things in the language more important to focus.
- vbezhenar 10y ago
  Jetbrains uses Kotlin for their own projects, including Intellij Idea. So you can be sure, that its support will be reasonably good, they use it themselves after all.

lmm 10y ago

> I feel kotlin is a bit undervalue. It is a great modern language which can replace java completely. It doesn't offer a compelling advantage. "Slightly cleaned-up Java with a bit of syntax sugar" is not enough to justify having to make all your tooling (IDEs, profilers, monitoring, code coverage ...) support a new language. And if you are going to make all that effort, why would you not pick a language that offers some genuine killer features in return, like Scala or Ceylon? And it's got a lot of special cases, a lot of stuff in the language that should just be libraries, that I think will make it hard to maintain in the long run (the "CoffeeScript of Java" line is probably fair). If anything it seems overhyped to me.

marc_omorain 10y ago
> "Slightly cleaned-up Java with a bit of syntax sugar" This is not an accurate description of Kotlin. Kotlin has many features that make it better than Java. Most importantly, it is null-safe. In addition to that it makes it simple to enforce data-immutability, which is very difficult in Java. https://kotlinlang.org/docs/reference/comparison-to-java.html https://kotlinlang.org/docs/reference/comparison-to-java.htm...
- lmm 10y ago
  > Kotlin has many features that make it better than Java. Most importantly, it is null-safe. In addition to that it makes it simple to enforce data-immutability, which is very difficult in Java. Kotlin does have nullability handling yes, but it's a very limited special-case feature - it's a language-level builtin rather than something you can use in your own libraries. E.g. if you want to have an error message in the failure case rather than just null (i.e. some kind of Result type), you can't reuse any of the null-safety functionality (whereas in Scala or Ceylon you can write the same methods to work with either optional/nullable or result-like types). Data immutability isn't at all difficult in Java. It's tedious (sprinkling "final" everywhere), but not hard.
  - hota_mazi 10y ago
    > it's a language-level builtin rather than something you can use in your own libraries The only people who still think that a library approach is superior to a compiler approach are Scala users. I'll clarify this for you: if it's a library construct, it can be ignored. And as a matter of fact, there is nothing in Scala forcing you to use `Option`. You can completely ignore it and enjoy your time diagnosing NullPointerExceptions everywhere. When a feature is enforced by the compiler, such as Kotlin and Ceylon, you don't get any easy way out: you have to think about null cases or you will not be able to compile your code. Period.