
Kotlin 1.2.20 released - dayanruben
https://blog.jetbrains.com/kotlin/2018/01/kotlin-1-2-20-is-out/
======
stewbrew
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
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
Yes, but I personally think this will be a problem for the long-term success
of kotlin.

~~~
_sdegutis
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
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.

~~~
smt88
If we could only use VSC, that would be fine because VSC is fantastic.

I've found the same of IntelliJ products. They're so good that I don't mind
being forced to use them.

------
bberrry
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
Agreed, its close to perfect. More elegant than Java, but with a much lower
mental load than Scala. Its just so tastefully done.

------
billfruit
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
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
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
> 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-nul...](http://arturdryomov.online/posts/kotlin-the-problem-with-null/)
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.

~~~
royjacobs
Why do you see options vs nulls as the same kind of interoperability issue as,
say, Scala's completely incompatible collections library? That seems a little
disingenuous.

~~~
lmm
Taken in isolation they're exactly the same kind of interoperability issue;
the difference is that Scala has the language facilities (typeclasses and
implicit conversions) to solve that kind of interoperability problem and
Kotlin does not. In Scala it's straightforward to write methods that work with
both Java and Scala collections (either at a syntactic level by using implicit
conversions or in a "true" way by using typeclasses); in Kotlin it's simply
impossible to write a method that will work with both options and nullables.

~~~
royjacobs
Having to work with Optionals in Kotlin means just using their Java API.
Having to work with Scala collections means having to convert them back and
forth every time you interop with Java. The performance implications of the
latter are much higher.

~~~
lmm
Almost all JVM projects are much more tightly constrained on development time
than on compute time - and those where compute time is the limiting factor are
unlikely to consider either Kotlin or Scala.

But in the vanishingly rare case where you have a performance-critical
codepath that needs to zigzag back and forth between Java and Scala... it's
still not a problem, because it's easy to work with the Java collections in
Scala. The absolute worst case is "just using their Java API" (the same thing
you dismiss about using Optionals in Kotlin). But since Scala has typeclasses
we can actually do much better than that.

------
ddon
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)

------
sus_007
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 ?

~~~
yoz-y
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.

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

~~~
fractalwrench
17% of Android Studio 3 projects were using Kotlin to some extent:
[https://android-developers.googleblog.com/2017/11/update-
on-...](https://android-developers.googleblog.com/2017/11/update-on-kotlin-
for-android.html)

------
phreack
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.

------
singularity2001
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
The integration is already very good (some little quirks notwithstanding).
What are you missing in that department?

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

~~~
relics443
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.

