8 ms·

Kotlin 1.2.20 released

73 points by dayanruben 9y ago

rsre 9y ago
Does anyone know where I can get some info about Kotlin usage statistics since Android made it an officially supported language?
- fractalwrench 9y ago
  17% of Android Studio 3 projects were using Kotlin to some extent: https://android-developers.googleblog.com/2017/11/update-on-kotlin-for-android.html https://android-developers.googleblog.com/2017/11/update-on-...
ddon 9y ago
Link to a changelog https://github.com/JetBrains/kotlin/blob/1.2.20/ChangeLog.md https://github.com/JetBrains/kotlin/blob/1.2.20/ChangeLog.md
billfruit 9y ago
Despite being a new language, what little I have seen of it looks pretty old school, i.e functional features seemed like an afterthought and also perhaps features like pattern destructuring and immutable data structures.
- lmm 9y ago
  In principle it's not that bad a language; compared to Swift or Typescript or even Rust it's at a similar level of conservatively adopting a few features that have become very mainstream. Every language design has to adopt a balance between making use of improvements that are coming down the pipeline and not adopting ideas that will later turn out to be bad. In a language built for the same platform where Scala has already been available for a decade it's very disappointing though.
  - cookiecaper 9y ago
    I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats. Kotlin's biggest strength is that it brings near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle. Boutique languages on the JVM are old hat by now, and they're neato and everything, but most people do not have the luxury of getting to choose to base their company on one of them. Kotlin is so compatible with Java that you can mix Java and Kotlin code freely in the same project, allowing people to move to adopt Kotlin gradually, without throwing away their extant business logic or requiring the wholesale sign-off of everyone in the org all at once. Kotlin may not be the most theoretically pure language, but it lets you hit the ground running while shedding many of the crusty, obnoxious parts of the Java language. We've badly needed a semi-modern JVM language for the working man, something that doesn't get in the way and makes the business of doing software simpler. That's why Kotlin has had such an ecstatic reception.
    - lmm 9y ago
      > I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats. SBT is indeed a wreck, just ignore it (at least to start with) and keep using whatever you were using (Maven or Gradle or what-have-you). In maven and eclipse/scala-ide with the m2eclipse-scala plugin installed I always found it "just worked": add the scala plugin to the pom, let eclipse notice that it's Scala, create a Scala class in the project and keep going. The IntelliJ experience is only very slightly more involved (have to manually tell IntelliJ to update the project config with Scala nature). > while it's ostensibly interoperable with Java, there are many caveats. > Kotlin's biggest strength is that it brings a reasonable amount of modernity with near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle. This is the Kotlin narrative but I don't think it's actually supported by the facts. In the early days Scala looked perfectly interoperable with Java, but as we started writing more substantial things in Scala and a native-to-Scala library ecosystem developed it became clear that there was more to interop than being able to call methods directly, as nice as the latter is. As Scala became a full-fledged language with its own idioms we started needing idiomatic wrappers or native-to-Scala libraries. This is happening in Kotlin too, e.g. look at how http://arturdryomov.online/posts/kotlin-the-problem-with-null/ http://arturdryomov.online/posts/kotlin-the-problem-with-nul... talks about having to consider whether calls are into Java libraries or not and treat them differently if they are. And if anything I'd say this is getting worse for Kotlin with "modern" Java code: Java 8 is seeing more use of Optionals (particularly in streams) which correspond directly to Scala but are more difficult to interoperate with in Kotlin with its null-oriented design.
- oblio 9y ago
  https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/multi-declarations.html https://kotlinlang.org/docs/reference/multi-declarations.htm... https://kotlinlang.org/docs/reference/collections.html https://kotlinlang.org/docs/reference/collections.html ?
  - Scarbutt 9y ago
    I don't know kotlin but if you read your collections link well, it does look like immutability was an afterthought, for starters, you can't create immutable persistent versions.
    - oblio 9y ago
      It's not an afterthought, it's just that Kotlin is meant to interoperate with Java. Which is mutable. However, if you look just at Kotlin's syntax, the default is meant to be immutable while the mutable version is longer: listOf versus mutableListOf. That looks very much like design and not like an afterthought.
      - lmm 9y ago
        There are no built-in immutable collection types; what Kotlin calls "immutable" is closer to C "const" i.e. it could be a view onto a list that's mutated elsewhere. This means you can't safely write a method that requires an immutable list; if you want to e.g. check the size of the list and then iterate over it, while maintaining the invariant that the number you got is the same as the number of iterations you're going to do, then you have to make a defensive copy, because there's no argument type you can ask for that means "actually immutable".
        relics443 9y ago
        `List<T>` is technically immutable. You can make it mutable by casting to `MutableList<T>`, but that's something you have to explicitly do.
- k__ 9y ago
  Yes, I was hoping Ceylon would make it, but whelp :)
- peheje 9y ago
  Could you elaborate on exactly what you dislike about these features? Or why they seem like an afterthought?
  - billfruit 9y ago
    I am not disliking these features, only was commenting that in my limited knowledge of Kotlin, functional features like these ( which I have come to like from using them in clojure) did not appear like the core design elements of the language. Like another commenter said below, in this regard Kotlin seems rather conservative in design.
    - cageface 9y ago
      Kotlin is a conservative design, but very pleasant to use with best-in-class tooling. I'd love to have a reason to use it on a real project. They hit the sweet spot on a lot of metrics with this design IMO.
- geodel 9y ago
  > Despite being a new language, It is a new language on JVM. It also suppose to work with Java libraries. So it won't radically different from Java.
- pdpi 9y ago
  It's important to note that Kotlin defines itself as a blue-collar language, and if the feel you get from it is "this is as if Java had been designed today", then they accomplished their goal. There's exactly one unusual/novel feature in the language (AIUI), and it's a feature that I personally find inspired: anonymous receiver functions, as it makes EDSLs trivial to write.
  - roflc0ptic 9y ago
    Are you familiar with Scala's implicits? Reading about them here (https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/lambdas.html), they seem very similar. If you happen to know, what affordances do anonymous receiver functions provide that implicits don't? It looks like they make it marginally easier to add functions to some existing type, but at the cost of making the typeclass pattern less palatable.
  - lmm 9y ago
    Delegation as implemented in Kotlin is very novel; AFAIK it's the first remotely mainstream language with that feature (not counting Go since it doesn't have traditional inheritance at all). (I think it's a very good idea, but it's as innovative as anything you'll see in e.g. Scala, so it makes a mockery of the "blue collar" narrative) Non-representable types are also decidedly "novel" (in the sense of "wtf?"), as are some of the details of their preferred way of doing await/async (assuming they haven't radically changed again in a minor version as they did in the past). The only sense in which Kotlin is blue-collar is that it prioritizes immediate use cases over consistency and theoretical coherence. That's not "Java as if it had been designed today", that's "Perl as if it had been designed today".
    - pdpi 9y ago
      Several features have a clear "this is annoying in Java" background: Type inference is table stakes for a modern language, data classes make beans painless, receiver methods are explicitly designed to ease the pain of FooUtils classes, inline+reified open up generics to a tonne more use cases, and variance annotations helps with several others.
bberrry 9y ago
I love Kotlin, it's been such a breath of fresh air at work. I hope it continues to gain adoption in backend services and not only Android, because it definitely shines at both.
- MrBuddyCasino 9y ago
  Agreed, its close to perfect. More elegant than Java, but with a much lower mental load than Scala. Its just so tastefully done.
singularity2001 9y ago
is the faster now? some seconds compilation time (even for hello world) is the only thing holding me back. (plus incomplete integration in IDEa)
- V-2 9y ago
  The integration is already very good (some little quirks notwithstanding). What are you missing in that department?
sus_007 9y ago
For somebody starting to learn Android Development, is it recommended to study Kotlin simultaneously with Java, or should I just master Java first before touching Kotlin ?
- Larrikin 9y ago
  Focus on Java, since 99% of online examples on the beginner side will be in Java and learning two language on top of Android will be a lot. There is no need to master Java before you begin learning Kotlin, but currently being able to convert between the two is still a requirement for effective development. Kotlin simply makes your life easier as a Java developer.
- thibran 9y ago
  Go with Java first. Kotlin fixes a lot of Java flaws and provides many Java-compatible solutions to those. Without knowing the flaws, you probably would have a hard time understanding the solutions.
- V-2 9y ago
  You can't escape learning Java (as of now), but it doesn't mean you can't follow it along learning Kotlin. It does not have to be one, then the other. It's just a matter of managing the cognitive load, and that's your private preference.
- yoz-y 9y ago
  I have done little Android development and none in Kotlin. However, if it is anything like the Obj-C to Swift transition, then I would recommend to learn to write programs in Kotlin but learn to read Java code. Most examples/tutorials/solutions will be in Java so you definitely need to understand them. However, I think it is better to write all new code in Kotlin.
phreack 9y ago
Kudos to the team on not just a sane style guide, but an IDE to help in keeping it! Not having to worry about this helps newbies a lot to focus on learning the language, so it's come far in becoming a great one to teach programming basics.
stewbrew 9y ago
I like Kotlin but I really wish they would draw a clearer line between kotlin the language (incl. compilers + generic tools) and the kotlin-plugin for IntelliJ IDEA. It seems they see the work on IDEA support for kotlin as an essential quality of new kotlin features. But guess what, there are people out there who don't want to use JetBrains' IDE, who prefer eclipse (for whatever reason) or who would be much happier to use an editor with LSP support. If JetBrains didn't make most of their money with their IDE, they would probably put more effort in providing general tools that can be used with any IDE/editor. In this sense, I think JetBrains is hampering the success of kotlin. They should try to give kotlin a better organisational foundation.
- V-2 9y ago
  That's sort of the point though, no? What's in it for them if they were to take care of Kotlin support on Eclipse - their competitor. They don't make their living off Kotlin
  - stewbrew 9y ago
    Yes, but I personally think this will be a problem for the long-term success of kotlin.
    - true_religion 9y ago
      Sure, but it's like windows and .net, even if they invest in usage outside their own native ecosystem it's going to be lackluster.
    - _sdegutis 9y ago
      Meh, I think IDE integration is an essential feature of a language. That’s why I use VS Code any time I write JS and only then.
      - stewbrew 9y ago
        Now imagine the only option to write JavaScript in a sensible way (however this should be possible :-) would be VSC. Do you really think JS would have had any success? I think it would have been another Visual Basic. Even typescript (a MS product) can be written with all sorts of IDEs/editors.
singularity2001 9y ago
making lists and maps first class citizens would be neat. mosty for esthetics: var x=immutableList(1,2,3) meh!
- relics443 9y ago
  I think the core team is opposed to it. IIRC it's because they don't want to surprise anyone with the type used for collection literals, but it might have been something else.

73 points by dayanruben 9y ago

rsre 9y ago

Does anyone know where I can get some info about Kotlin usage statistics since Android made it an officially supported language?

fractalwrench 9y ago
17% of Android Studio 3 projects were using Kotlin to some extent: https://android-developers.googleblog.com/2017/11/update-on-kotlin-for-android.html https://android-developers.googleblog.com/2017/11/update-on-...

ddon 9y ago

Link to a changelog https://github.com/JetBrains/kotlin/blob/1.2.20/ChangeLog.md https://github.com/JetBrains/kotlin/blob/1.2.20/ChangeLog.md

billfruit 9y ago

Despite being a new language, what little I have seen of it looks pretty old school, i.e functional features seemed like an afterthought and also perhaps features like pattern destructuring and immutable data structures.

lmm 9y ago
In principle it's not that bad a language; compared to Swift or Typescript or even Rust it's at a similar level of conservatively adopting a few features that have become very mainstream. Every language design has to adopt a balance between making use of improvements that are coming down the pipeline and not adopting ideas that will later turn out to be bad. In a language built for the same platform where Scala has already been available for a decade it's very disappointing though.
- cookiecaper 9y ago
  I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats. Kotlin's biggest strength is that it brings near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle. Boutique languages on the JVM are old hat by now, and they're neato and everything, but most people do not have the luxury of getting to choose to base their company on one of them. Kotlin is so compatible with Java that you can mix Java and Kotlin code freely in the same project, allowing people to move to adopt Kotlin gradually, without throwing away their extant business logic or requiring the wholesale sign-off of everyone in the org all at once. Kotlin may not be the most theoretically pure language, but it lets you hit the ground running while shedding many of the crusty, obnoxious parts of the Java language. We've badly needed a semi-modern JVM language for the working man, something that doesn't get in the way and makes the business of doing software simpler. That's why Kotlin has had such an ecstatic reception.
  - lmm 9y ago
    > I've had nothing but trouble trying to get Scala bootstrapped (sbt is a wreck), and while it's ostensibly interoperable with Java, there are many caveats. SBT is indeed a wreck, just ignore it (at least to start with) and keep using whatever you were using (Maven or Gradle or what-have-you). In maven and eclipse/scala-ide with the m2eclipse-scala plugin installed I always found it "just worked": add the scala plugin to the pom, let eclipse notice that it's Scala, create a Scala class in the project and keep going. The IntelliJ experience is only very slightly more involved (have to manually tell IntelliJ to update the project config with Scala nature). > while it's ostensibly interoperable with Java, there are many caveats. > Kotlin's biggest strength is that it brings a reasonable amount of modernity with near-perfect Java interoperability. Almost any code that runs on a JVM released in the last 10 years will interoperate with Kotlin with minimal hassle. This is the Kotlin narrative but I don't think it's actually supported by the facts. In the early days Scala looked perfectly interoperable with Java, but as we started writing more substantial things in Scala and a native-to-Scala library ecosystem developed it became clear that there was more to interop than being able to call methods directly, as nice as the latter is. As Scala became a full-fledged language with its own idioms we started needing idiomatic wrappers or native-to-Scala libraries. This is happening in Kotlin too, e.g. look at how http://arturdryomov.online/posts/kotlin-the-problem-with-null/ http://arturdryomov.online/posts/kotlin-the-problem-with-nul... talks about having to consider whether calls are into Java libraries or not and treat them differently if they are. And if anything I'd say this is getting worse for Kotlin with "modern" Java code: Java 8 is seeing more use of Optionals (particularly in streams) which correspond directly to Scala but are more difficult to interoperate with in Kotlin with its null-oriented design.
oblio 9y ago
https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/multi-declarations.html https://kotlinlang.org/docs/reference/multi-declarations.htm... https://kotlinlang.org/docs/reference/collections.html https://kotlinlang.org/docs/reference/collections.html ?
- Scarbutt 9y ago
  I don't know kotlin but if you read your collections link well, it does look like immutability was an afterthought, for starters, you can't create immutable persistent versions.
  - oblio 9y ago
    It's not an afterthought, it's just that Kotlin is meant to interoperate with Java. Which is mutable. However, if you look just at Kotlin's syntax, the default is meant to be immutable while the mutable version is longer: listOf versus mutableListOf. That looks very much like design and not like an afterthought.
    - lmm 9y ago
      There are no built-in immutable collection types; what Kotlin calls "immutable" is closer to C "const" i.e. it could be a view onto a list that's mutated elsewhere. This means you can't safely write a method that requires an immutable list; if you want to e.g. check the size of the list and then iterate over it, while maintaining the invariant that the number you got is the same as the number of iterations you're going to do, then you have to make a defensive copy, because there's no argument type you can ask for that means "actually immutable".
      - relics443 9y ago
        `List<T>` is technically immutable. You can make it mutable by casting to `MutableList<T>`, but that's something you have to explicitly do.
k__ 9y ago
Yes, I was hoping Ceylon would make it, but whelp :)
peheje 9y ago
Could you elaborate on exactly what you dislike about these features? Or why they seem like an afterthought?
- billfruit 9y ago
  I am not disliking these features, only was commenting that in my limited knowledge of Kotlin, functional features like these ( which I have come to like from using them in clojure) did not appear like the core design elements of the language. Like another commenter said below, in this regard Kotlin seems rather conservative in design.
  - cageface 9y ago
    Kotlin is a conservative design, but very pleasant to use with best-in-class tooling. I'd love to have a reason to use it on a real project. They hit the sweet spot on a lot of metrics with this design IMO.
geodel 9y ago
> Despite being a new language, It is a new language on JVM. It also suppose to work with Java libraries. So it won't radically different from Java.
pdpi 9y ago
It's important to note that Kotlin defines itself as a blue-collar language, and if the feel you get from it is "this is as if Java had been designed today", then they accomplished their goal. There's exactly one unusual/novel feature in the language (AIUI), and it's a feature that I personally find inspired: anonymous receiver functions, as it makes EDSLs trivial to write.
- roflc0ptic 9y ago
  Are you familiar with Scala's implicits? Reading about them here (https://kotlinlang.org/docs/reference/lambdas.html https://kotlinlang.org/docs/reference/lambdas.html), they seem very similar. If you happen to know, what affordances do anonymous receiver functions provide that implicits don't? It looks like they make it marginally easier to add functions to some existing type, but at the cost of making the typeclass pattern less palatable.
- lmm 9y ago
  Delegation as implemented in Kotlin is very novel; AFAIK it's the first remotely mainstream language with that feature (not counting Go since it doesn't have traditional inheritance at all). (I think it's a very good idea, but it's as innovative as anything you'll see in e.g. Scala, so it makes a mockery of the "blue collar" narrative) Non-representable types are also decidedly "novel" (in the sense of "wtf?"), as are some of the details of their preferred way of doing await/async (assuming they haven't radically changed again in a minor version as they did in the past). The only sense in which Kotlin is blue-collar is that it prioritizes immediate use cases over consistency and theoretical coherence. That's not "Java as if it had been designed today", that's "Perl as if it had been designed today".
  - pdpi 9y ago
    Several features have a clear "this is annoying in Java" background: Type inference is table stakes for a modern language, data classes make beans painless, receiver methods are explicitly designed to ease the pain of FooUtils classes, inline+reified open up generics to a tonne more use cases, and variance annotations helps with several others.

bberrry 9y ago

I love Kotlin, it's been such a breath of fresh air at work. I hope it continues to gain adoption in backend services and not only Android, because it definitely shines at both.

MrBuddyCasino 9y ago
Agreed, its close to perfect. More elegant than Java, but with a much lower mental load than Scala. Its just so tastefully done.

singularity2001 9y ago

is the faster now? some seconds compilation time (even for hello world) is the only thing holding me back. (plus incomplete integration in IDEa)

V-2 9y ago
The integration is already very good (some little quirks notwithstanding). What are you missing in that department?

sus_007 9y ago

For somebody starting to learn Android Development, is it recommended to study Kotlin simultaneously with Java, or should I just master Java first before touching Kotlin ?

Larrikin 9y ago
Focus on Java, since 99% of online examples on the beginner side will be in Java and learning two language on top of Android will be a lot. There is no need to master Java before you begin learning Kotlin, but currently being able to convert between the two is still a requirement for effective development. Kotlin simply makes your life easier as a Java developer.
thibran 9y ago
Go with Java first. Kotlin fixes a lot of Java flaws and provides many Java-compatible solutions to those. Without knowing the flaws, you probably would have a hard time understanding the solutions.
V-2 9y ago
You can't escape learning Java (as of now), but it doesn't mean you can't follow it along learning Kotlin. It does not have to be one, then the other. It's just a matter of managing the cognitive load, and that's your private preference.
yoz-y 9y ago
I have done little Android development and none in Kotlin. However, if it is anything like the Obj-C to Swift transition, then I would recommend to learn to write programs in Kotlin but learn to read Java code. Most examples/tutorials/solutions will be in Java so you definitely need to understand them. However, I think it is better to write all new code in Kotlin.

phreack 9y ago

Kudos to the team on not just a sane style guide, but an IDE to help in keeping it! Not having to worry about this helps newbies a lot to focus on learning the language, so it's come far in becoming a great one to teach programming basics.

stewbrew 9y ago

I like Kotlin but I really wish they would draw a clearer line between kotlin the language (incl. compilers + generic tools) and the kotlin-plugin for IntelliJ IDEA. It seems they see the work on IDEA support for kotlin as an essential quality of new kotlin features. But guess what, there are people out there who don't want to use JetBrains' IDE, who prefer eclipse (for whatever reason) or who would be much happier to use an editor with LSP support. If JetBrains didn't make most of their money with their IDE, they would probably put more effort in providing general tools that can be used with any IDE/editor. In this sense, I think JetBrains is hampering the success of kotlin. They should try to give kotlin a better organisational foundation.

V-2 9y ago
That's sort of the point though, no? What's in it for them if they were to take care of Kotlin support on Eclipse - their competitor. They don't make their living off Kotlin
- stewbrew 9y ago
  Yes, but I personally think this will be a problem for the long-term success of kotlin.
  - true_religion 9y ago
    Sure, but it's like windows and .net, even if they invest in usage outside their own native ecosystem it's going to be lackluster.
  - _sdegutis 9y ago
    Meh, I think IDE integration is an essential feature of a language. That’s why I use VS Code any time I write JS and only then.
    - stewbrew 9y ago
      Now imagine the only option to write JavaScript in a sensible way (however this should be possible :-) would be VSC. Do you really think JS would have had any success? I think it would have been another Visual Basic. Even typescript (a MS product) can be written with all sorts of IDEs/editors.

singularity2001 9y ago

making lists and maps first class citizens would be neat. mosty for esthetics: var x=immutableList(1,2,3) meh!

relics443 9y ago
I think the core team is opposed to it. IIRC it's because they don't want to surprise anyone with the type used for collection literals, but it might have been something else.