back
54 comments
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.

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
Yes, but I personally think this will be a problem for the long-term success of kotlin.
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.
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.

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.

C# and Swift are in that boat (VS and Xcode) but they’re doing alright, because they’re the main blessed languages for their platforms. JS is the only blessed language of web front ends. So yeah I don’t think IDE lock-in is a concern for JS but it definitely makes me happier as a developer to have deep integration that makes my job easier.
If VSC + JS would be free, open source and running on all platforms, why not?
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.
This is my exact gripe. I appreciate that they've invested a serious amount of time and effort into creating an entire language for the JVM. But I am bummed about how tied it is to the IDE experience. Writing Go or Rust in Vim is relatively painless. I've written a few minor things in Kotlin and Kotlin/Vert.x and the non-IDE experience is pretty craptastic. Almost all docs assume you'll write some code, and some IDE will automatically add imports for you.

I left the Java world because I couldn't stand having to have all of the hand holding just to achieve simple goals. I'm not saying Java or Kotlin are _bad_ languages at all. Perhaps I'm just bugged by the general attitude that "everyone will have IntelliJ".

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

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.

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

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.
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.
> In a language built for the same platform where Scala has already been available for a decade it's very disappointing though.

Given that after literally years of Scala experience I could easily write code I couldn't read three months later, this is not a big negative.

Kotlin takes a lot of the good from Scala, leaves most of the bad, and gets the hell out of my way (while giving me literally-perfect Java interop--the only problem I ever had was how to annotate only the getter part of a property, and it was unintuitive but I figured it out). I'm a big fan.

To me it feels like they took the sugar from Scala but not the meat. All the simple examples of monads like Future work but with their own ad-hoc solutions (e.g. async/await) so there's no way to implement the reusable library functions that give them their real power. Direct pattern matching is there but the generic tree traversals that give you the real power of ADTs are impossible. All the one-page examples of "Scala power" are there but if you look closely they all fall apart once you try to expand them into the things you do in a full-size codebase.
Sure--but every time I do those things in a full-size codebase, I regret it later. ;) Scala is cool. I like a lot of the people involved (especially since Tony Morris was shown the door). But trying to get something out the door that doesn't turn into a mess of code I have to sit down and chew through, slo-oo-owly, is a heck of a fight. And it's worse when other people's preferred bits-and-bobs of Scala start sneaking in (kind of like C++, in a way!).

The complexity I end up carrying in my head is way, way too high.

> Sure--but every time I do those things in a full-size codebase, I regret it later.

Hmm, that's backwards from my experience. Like, I actually regret it when I use the Future-specific operations on Futures, because I don't use those often enough to remember what they are, whereas I use the generic Monad operations all the time on pretty much everything.

> trying to get something out the door that doesn't turn into a mess of code I have to sit down and chew through, slo-oo-owly, is a heck of a fight

I find often something that would be 10 lines of Java or Kotlin can be 1 line of Scala - but still 8 lines' worth of reading time. It can be difficult to remember that this is an improvement when you're thinking "why is it taking me all morning to read 10 lines?", but when you take a step back you realise that those 10 lines are actually doing the work of many more.

https://kotlinlang.org/docs/reference/lambdas.html

https://kotlinlang.org/docs/reference/multi-declarations.htm...

https://kotlinlang.org/docs/reference/collections.html

?

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

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

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

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.
Sure, it does fix some of the annoying things in Java, as do most languages from the last ten years. But it does also make radical moves away from it - the narrative that you could easily port any Kotlin codebase to vanilla Java becomes a complete myth once you start using delegation or async/await. From my perspective Kotlin tries to have it both ways and ends up achieving neither: it's different enough from Java that you have to treat it as a whole new language, but the lack of usable result types or structured/safe ways to do things like JSON serialization makes it looks painfully limited next to Scala. Indeed by lacking any practical way to safely report errors with information (it's missing checked exceptions but doesn't have practical result types either, because there's no "do notation"-like syntax - the "elvis operator" and friends only work with null, not with errors that carry information), in an important respect it's a regression from Java.
Are you familiar with Scala's implicits? Reading about them here (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.
Yes, I was hoping Ceylon would make it, but whelp :)
> 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.

Could you elaborate on exactly what you dislike about these features? Or why they seem like an afterthought?
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.
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.
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 ?
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.

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.
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.
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.
Does anyone know where I can get some info about Kotlin usage statistics since Android made it an officially supported language?
17% of Android Studio 3 projects were using Kotlin to some extent: https://android-developers.googleblog.com/2017/11/update-on-...
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.
is the faster now? some seconds compilation time (even for hello world) is the only thing holding me back. (plus incomplete integration in IDEa)
The integration is already very good (some little quirks notwithstanding). What are you missing in that department?
making lists and maps first class citizens would be neat. mosty for esthetics: var x=immutableList(1,2,3) meh!
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.