Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Has anyone here programmed in Kotlin? What do you think about it?
190 points by lemevi on July 25, 2015 | hide | past | favorite | 199 comments
I was looking at Kotlin and was curious. It looks very interesting feature wise but I worry about its long term viability given it's low presence on GitHub[1] and < 40 users on #kotlin on Freenode IRC. Is this worth writing a big project in?

[1] https://github.com/search?o=desc&q=language%3AKotlin&ref=searchresults&s=stars&type=Repositories&utf8=




I started an open source Android project in Kotlin (https://github.com/dodyg) three years ago so I have witnessed the language evolution from early on.

This is what I love about Kotlin:

- It is IMHO the best language to develop native application in Android by far.

- I was primarily a C# developer (still now) and I could pick up the language in a day. The language is quite small for people that has already known a programming language.

- JetBrains is taking their time to get the language right. There is no 'swift syndrome' here.

- They are really serious about the Java 100% compatibility.

- The IDE support is world class.

- It is a really pleasant language to use.

- JetBrains is actually using the language for their own products.

- The community is friendly and the language designers are approachable.

- You can really mix and match Java and Kotlin code in the same project. You don't have to use it only in a green field projects.


What is the 'swift syndrome'?


Swift was developed in secret and launched to unsuspecting public in near 'complete' status in 2014 then a 1.2 version quickly followed. Now it is version 2.0 after one year of launch. That is some serious version inflation.

Kotlin was developed in the open from much of its development and you can see how the language evolves based on the feedback of early adopters. There is no rush to 1.0 until they feel they got the right mix of features.

I just think the way Jetbrains approached the development of the language is more responsible and it bodes well for future iteration of the language.


probably hyping the language beyond reason, despite it being an unfinished product at that time.

but the hype was mostly done by the apple disciples iirc, so it might be a little unfair to hold that against the language.


Im guessing making somwhat radical decision that are not backwards compatible.

However, Python 2/3 is a better example for breaking backwards compatibility.


I just started learning Swift, and I keep running into stackoverflow answers saying "Here's how it worked in 1.0. In 1.2 you have to do this instead. But in 2.0 you do it this other way."


I would imagine based on the context of the sentence, that as JetBrains are taking their time with the language, they aren't rushing through developing it further and making mistakes etc.

But I could be wrong.


For me, the swift language is becoming dangerously like Scala. It's becoming a really large language syntax-wise. Trying to incorporate too many features.


When you say "Java 100% compatibility", does it mean you can rename a .java to .kotlin and kotlin compile would never complain?


You can mix and match Java files and Kotlin files in the same project without a problem. Also, for any Java file you can ask IDEA's Kotlin plugin to automatically convert it to Kotlin for you, and likewise if you cut-and-paste Java code into a Kotlin file it will ask if you want to rewrite that code block.


I think more importantly. You can interact with any Kotlin class from Java, and vice versa.


Kotlin's tooling for Java interop should go down in the textbooks as the prime standard for how to ease a programming language built for a run-time to mainstream adoption. It's just phenomenal.

Not that Kotlin is introducing anything like this, but, I wonder if this sets a precedent going forward for popular programming tooling vendors to evolve as the primary distribution point for introducing new programming language research and paradigms to the industry.


As someone who knows C# & JavaScript well and has been occasionally playing around with Go, I think you've convinced me to give Kotlin a try for some Android development. Hopefully it's as easy to pick up as you say. It's been quite a while since I've done much of anything with Java.


Can you elaborate on what Kotlin doesn't get right? Surely there's something. Just trying to get a more balanced perspective here.


I wrote about Kotlin quite some time ago.[0] I have to say that at the time, I was quite impressed by it all. There were some really good features, it had a much smaller dependency compared to Scala, and so packaging a Kotlin application was a lot easier than say an application in Scala. But to answer your question, there are a few benefits and drawbacks of Kotlin as a language and a platform:

+ World class IDE support.

+ Simple Language, that isn't as complicated as Scala (but this really depends on what features you end up using) but is expressive nonetheless.

+ Really good Java compatibility (if that matters to you that is).

- Language still does not have a 1.0 (although for a few GUI apps I've done, things are pretty stable)

- Language has poor documentation compared to the likes of Java and Scala

- Language has few learning resources (but two people in the Kotlin team are working to change that)

As far as Android development goes, Android Studio is built on top of the IntelliJ platform (which is Jetbrains' product) so I think you'll get really good android development support for Kotlin although I'm a little indifferent to this. I think that at one point go is going to become the defacto language for Android since google likes to keep everything in-house.

[0] http://nafiulis.me/kotlin-koans-i.html


"I think that at one point go is going to become the defacto language for Android since google likes to keep everything in-house."

As someone who writes Android/Java code for the day job but who prefers coding in Go whenever I have the chance, I'd love for this happen but I doubt it will anytime in the foreseeable future.

There's just way too much invested in all of the Android Java Platform/UI/etc APIs which would make little to no sense in Go even if you had good bindings for them.

Go will be increasingly supported in Android and it'll get some uptake from people writing games and apps that are primarily OpenGL based, but I just don't see how they could (without investing an absolute giant amount of resources and causing all sorts of developer balkanization), get from where the Android platform is now to an equivalent environment that is properly Go-esque for apps that make heavy use of the higher level platform APIs.


I had kinda hoped that the lawsuit over Java APIs would give them motivation to switch to Golang. :(


I hope not. There are plenty of people who would rather use even Java 6 than Go, and Kotlin is dramatically better than either of them.


Regarding documentation, while you're right, I'd like to point out that Kotlin intentionally has a minimal standard library. The Java standard library is Kotlin's standard library (modulo some minor additions), and Kotlin is designed to make using the same APIs a lot nicer -- not to replace them with Kotlin-specific APIs. The preferred approach for creating a "Kotlin wrapper" if one is necessary is simply adding extension methods to the Java class. So while more detailed Kotlin documentation would certainly help, it requires much thinner documentation than other JVM languages that package their own rich standard libraries.


> The preferred approach for creating a "Kotlin wrapper" if one is necessary is simply adding extension methods to the Java class.

You nailed it. I think that this is ultimately something that JetBrains must stress in their documentation and have extensive examples on how to go about doing this if Kotlin is to get much more widespread adoption.


At JetBrains we're using Kotlin on a few projects now. Some of them are internal, some are public facing. In addition, some of our existing (and new) products are now using Kotlin. IntelliJ IDEA 15 will be shipping with Kotlin plugin enabled by default.

Kotlin is a tool we created out of need. We're using it and we're relying on it, so I'd say it's got a very good long term viability.


What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange.

Also I still miss a good build tool. I mean Maven really sucks, Gradle is kind of okai, but there is no support of autoreload project on change (like sbt has via sbt-revolver or playframework internals) however that is mostly helping web development.

Also some other things aren't really written out, like threading or some kind of Akka stuff. Also these days a language needs Dependency Injection, a good Integration with JSR330 would be great.

Also for some functional workflows something like pattern matching would be great and a @tailrec annotation like scala.

And please, for gods sake, remove labels and break/while.


> What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange.

Why?

> I mean Maven really sucks

Why?

> Also these days a language needs Dependency Injection

There's plenty of JVM libraries that provide it. Why does a language need to provide it?


> I mean Maven really sucks

Why?

I think after a while one gets tired of using XML as a configuration language. It's verbose and not the easiest to read. Beyond that, we used to find ourselves in dependency hell with maven pretty frequently, though that hasn't happened to me in a few years.

The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself.

I've written a maven plugin, and the documentation/support was rather poor. I also found myself having to use an older version of various plugin libraries in order to write proper tests for the plugin. It took me a couple of weeks. Had I done all that in Gradle, I could have just thrown in a few lines of groovy and probably finished in a day.

That said, it's stable and well known. Gradle seems to have the momentum and increasing mindshare, but you probably won't get fired for using maven.


> Beyond that, we used to find ourselves in dependency hell with maven pretty frequently

You'll hit that with Gradle, Ivy, Leiningen, SBT and Buildr too.

> The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself.

I'd also call that it's biggest strength. Maven POMs are only ever declarative. I've never hit a FOSS project using Maven that I couldn't build, but I've hit plenty using SBT or Ant that I had to tweak to build.

> I've written a maven plugin, and the documentation/support was rather poor.

I had the same experience with Gradle's DSL documentation, although having a look at it now, they've dramatically improved it since then.


> Had I done all that in Gradle, I could have just thrown in a few lines of groovy and probably finished in a day

"Probably"? "Thrown in"? Perhaps you can cut and paste build scripts between Gradle projects, but write anything more than "a few lines" in Groovy and you're looking at huge maintenance problems, like something that evaluated as ["abc", "defg", "hij"] suddenly becoming ['a', 'b', 'c'] for reasons that become apparent only after hours of printing debug messages.


I think that calling something verbose and unreadable is an oxymoron. XML is very explicit about what each field is labeled. Having an XSD means you always know what field is available where and what type of values are permitted. BUT, if you're still not happy, there's always polyglot maven[1]

[1] https://github.com/takari/polyglot-maven


Why why why do do do you you you think think think that that that a a a language language language that that that was was was verbose verbose verbose could could could not not not also also also be be be unreadable unreadable unreadable ?<question> ?<question> ?<question>


It took me until the question marks to realize that the words were repeated.

Weird.


> I think that calling something verbose and unreadable is an oxymoron.

Verbose and unreadable are not contradictory descriptions. In fact, they are more complementary descriptions -- there is a reason that in natural languages one of the most frequent recommendations for clear and readable writing is to be concise.

Excess verbosity is bad for readability.


Indeed, but it could be argued that excess verbosity might be better for long-term maintainability. Not that I'm defending the topic at hand here: XML as a configuration language.


Interesting you say that because I feel that XML is a bit oxymoronic a priori. They wanted something both human and machine readable, but fails to be great at either.


Currently it sucks to write tests with JUnit while using Kotlin, there is Spek (Jetbrains made it(, but it's early (too early).

XML based Build Tool, I mean seriously? It should at least be somehow human readable.

A language should need a sane integration of it, not the library itself. Okai DI is definitly somewhat that isn't needed, but a good integration is still suitable.

I mean good Multithreading lives in RxKotlin which is based on RxJava, however I still think that Threading or some kind of Library which should handle mutli prozessors / async capabilities should live INSIDE the language (like go, erlang or lots of others).

I mean currently Java9 will get a lot of new things which will definitely help out Scala to compile faster and Java10 will bring these closer. So there is no real reason for a language that still lacks a lot of stuff. As already said, Kotlin is small, on some edges thats good, on some it's just too small and I don't get it why they built while, break and continue into a somewhat functional language. Especially when while, break and continue is really hard to handle / read.


IMHO, I'm not sure if any of the above there besides the testing libraries is something that should be part of Kotlin, _especially_ if it hasn't even yet hit v1.0.

That having been said, I think your concerns will be addressed, _eventually_, but JetBrain is not trying to disrupt Java or its ecosystem before mainstream adoption of the language.

Re: async capabilities like Erlang/Go, until the JVM can support continuations, an industry standard solution like bytecode instrumentation, which Java9 will improve on, will entrench libraries like Quasar / RxKotlin to be basically drop in. These libraries provide seamless interoperability with existing synchronous libraries (see https://github.com/puniverse/comsat) to get around the fact that Erlang's/Go's async capabilities are not built-in to the language.


There is Quasar if you want Go or Erlang style concurrency in either Java or Kotlin (and the Pulsar wrapper to it for Clojure).

No reason to bake it into the language -- and as you can see from comparing the Java and Kotlin sample code, there is a reason for a language that let you write Groovy-like DSLs.

http://docs.paralleluniverse.co/quasar/


>> No reason to bake it into the language

Go-style channels and goroutines are built on green threads which Go/Erlang has, but the JVM does not have. One way to work around this is to use fibers and continuations which is what Quasar is doing.


For tests : I have had some nice experience writing jUnit tests with pitest (PIT) : there is a gradle plugin to do that in AS/Idea

The only issue I had was to ignore Package class to make pit work

For DI, Dagger2 works fine with kotlin

For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)


> For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)

Have you opened up an issue on Quasar's repo (https://github.com/puniverse/quasar) so Parallel Universe can track this for a possible milestone?


We don't need to : I read somewhere that it was on their roadmap...


If you want easy multithreading on Android take a look at Kovenant http://kovenant.komponents.nl/android/features/


Can you use PIT with Kotlin? Really tempted to try it out but wasn't sure. I suppose if it works at the bytecode instead of source level it would just work.


Yes you can (I managed it and it works beautifully). But you have to make it ignore Package Class at the moment because top functions in a package (say my.great.pack) can be in different .kt files and are gathered in a single class (my.great.pack.PackPackage) and pit doesn't seem to be able to cope with a class whose source come from more than 1 file (or I missed something).

Just put something like this in your gradle.build file :

apply plugin: "info.solidsoft.pitest"

pitest { targetClasses = ['org.lakedaemon.suggest.', 'org.lakedaemon.compress.'] //by default "${project.group}." excludedClasses = ['org.lakedaemon.compress.decoders.DecodersPackage', 'org.lakedaemon.compress.decoders.EncodersPackage'] avoidCallsTo = ['org.apache.log4j.', 'org.lakedaemon.L.', 'org.slf4j.', 'java.util.logging.'] pitestVersion = "1.1.4" //not needed when a default PIT version should be used threads = 4 outputFormats = ['XML', 'HTML'] enableDefaultIncrementalAnalysis = true testSourceSets = [sourceSets.test/, sourceSets.integrationTest/] mainSourceSets = [sourceSets.main/, sourceSets.additionalMain*/] }


> Currently it sucks to write tests with JUnit while using Kotlin

Why?

> XML based Build Tool, I mean seriously? It should at least be somehow human readable.

It's entirely human readable in my subjective opinion. At the very least, it's as human readable as HTML...

> A language should need a sane integration of it, not the library itself.

Any language which has constructors already has the best DI integration available.


Gradle 2.5 has (finally) added continuous build support


Do you still accept feedback about all those ugly ...@label, e.g. break@label?

I really dislike it. Couldn't it at very least have a space between keyword and label?


Are you referring to labels or annotations? Annotations now use @. Labels are label@, break@label still remains.


What was the need that Kotlin arose out of?


To summarize, we were looking for a language that could cut down our code base (IntelliJ platform and server side tools are written in Java), be concise but still expressive, toolable, as fast as Java, easy ramp-up time, and very important, interoperable with all the existing code base we had.

Given the candidates at the time, it was decided to start Kotlin.


Based on my admittedly limited experience in the JVM world, your needs sounds like Scala's sales pitch. What factored in to your decision to develop Kotlin, rather than going with Scala?


The two languages have completely different philosophies. Kotlin is a strict adherent of the Java philosophy[1], a "blue collar language" that adopts only tried-and-true features, with PL research being a non-goal. Scala OTOH, adopts almost every new PL concept, and PL research is very much one of its goals. A quick look at Scala's list implementation will show you how different those languages are. Kotlin is a modern Java; Scala is a Haskell/OOP/macros combo.

Yet, I think many of Scala's users will find that Kotlin gives them all they need, in a much simpler, more readable and maintainable language. If, however, you're aching to write type-safe monad transformers, you're bound to be disappointed by Kotlin.

[1]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....


As the Scala tech lead, I'm glad to learn we've finally adopted "almost every new PL concept!" I guess by now everyone will recognize your username and adjust for bias accordingly, but still, how about sticking to the facts?


As someone who doesn't follow such things (eg; I don't recognize the "pron" or "adriaanm" usernames, and haven't used Scala or any other JVM language), I found your comment to be a turn-off towards using Scala. That's not the kind of mature tone I'd look for from the tech lead of an open-source language.

That said, it is good to know that "pron" was incorrect/exaggerating when they said Scala adopts a lot of PL concepts; thanks for setting the record straight (though I'm still just not sure where Scala stands on that after reading this).


FYI, pron's the author of a would be competing project to Scala's Akka (i.e. competing for share of distributed computing market on the JVM), and takes every opportunity to danger-danger-dragons-be-there on Scala related threads/comments.

Saying that, there is always some truth in what pron brings to the table, it's sort of a higher kinded trolling ;-)

As for Scala and PL concepts, sure, plenty on offer if that's of interest, but not at all a requirement in using the language. A great example of a highly successful project based on the non-FP-centric aspects of Scala is Spark. See their high performance computing style guide [1], no monad transformers there...

[1] https://github.com/databricks/scala-style-guide


FYI, I had taken "every opportunity to danger-danger-dragons-be-there" Scala — on record — years before I even dreamed of the database company that would one day have an open-source project which would end up competing with Akka (I'm talking 2009/10, while Quasar was first conceived in mid 2013).

It was after leading an attempt to adopt Scala at a large organization, which failed because of what I saw as Scala's bait-and-switch marketing: it presented itself as "a better Java" while it really was (and is) a strict-Haskell-with-OOP-and-macros-and-more. We needed a car and got a helicopter. While some would consider a helicopter superior to a car, I think everyone would agree it imposes a completely different set of tradeoffs. So yeah, for a good while I was telling people, listen, it's a helicopter, so make sure a helicopter is what you want (the Scala community’s response was, what is this FUD? Can’t you see it's got wheels?! You can drive it on the ground if you want; you don’t have to take off! To which I responded, but you still can’t take it to a car garage for maintenance, to which their response was, you’re a stupid biased troll!). I don't remember when was the last time I participated in a Scala thread, but that community doesn’t forget. So if I'm damned if I don't, I might as well do:

Spark is a good example for a project that would have been better off using Kotlin. They wouldn't have missed any Scala features, would have had better build times, better IDE support and better Java interop (of course, Kotlin wasn’t mature enough to even be considered when that project started). In fact, using Kotlin would have saved them writing 95% of that style-guide[1], which reads like instructions on how to drive a helicopter on the ground without accidentally taking off (Perhaps ironically, that style guide drew derision from the Scala community, who said, you're in a helicopter for fuck's sake! Why won't you take off?!)

[1]: No implicits, no multiple argument lists, no Try, no infix notation, no non-math operators, no recursion, no being-fancy-with-monads, no Scala concurrent collections, no Scala collections, no for loops. They don't mention dynamics and structural types, but I think it goes without saying that they're off-limits, too.


Interesting analogy, incredible how Spark drives the Scala helicopter like a car; they seem to have nailed parallel parking ;-)

Seriously though, I doubt Kotlin would ever be the first choice for a project like Spark since Scala excels in the DSL department (really without rival on the JVM, and off, only Haskell comes close). Look through Spark source code [1] and you'll see: operator overloading, (sealed) ADTs, exhaustive pattern matching, etc. functionality that you can't even think the thought in in a language like Kotlin. This has nothing to do with monad transformers and other FPisms, just straight DSL power.

Finally, to put things in perspective in terms of the mindhsare that Scala and its ecosystem are drawing, IBM is investing over 100 million dollars per year in Spark research and development [2]. Sorry, but that's absolutely massive, maybe there are no dragons? Or if there are, the big players don't seem overly bothered.

[1] https://github.com/apache/spark/blob/master/sql/catalyst/src...

[2] https://www-03.ibm.com/press/us/en/pressrelease/47107.wss


Do you actually know Kotlin? It has many features for DSL support, including operator overloading (though not the ability to invent random new operators fortunately), infix notation, a form of exhaustive pattern matching, extension functions, annotation processing, inlineable anonymous extension functions which sounds bizarre but actually is key to defining many DSLs in the language, and so on. It's a different approach to Scala but to say there's no way to do DSLs isn't right.

As an example, check out funKtionale. It's a library that adds various functional features like function currying and partial application to Kotlin, entirely by using its DSL features.


Or our Kotlin actor API: http://blog.paralleluniverse.co/2015/06/04/quasar-kotlin/


1. None of those features (except sealed ADTs, which really aren't necessary) is missing from Kotlin. The set of Scala features Spark is using is pretty much identical to Kotlin.

2. I don't see how IBM's investment has anything to do with Scala, though. Spark is a great product, and deserves an investment even if it were written in BASIC.

3. Even if Spark did rely on Scala features that aren't in Kotlin (it doesn't), Spark is a library/framework/middleware completely unlike enterprise projects. It is orders of magnitude smaller, for one. That is not to say it isn't awesome, but I wouldn't extrapolate from its choice of technologies (including the language) to the enterprise.

4. Clojure makes writing DSLs easier and with far less magic. Groovy DSLs are also as powerful as Scala's and easier to write. Kotlin DSLs are not as powerful, but are more than enough for Spark.

5. I've never, ever, said Scala is unusable. In fact, I've always said (and believed), it is a very powerful language. I have said that that kind of power is not what most companies want or need, and that that kind of unopinionated kitchen-sink, cutting-edge language is probably not suitable for long-time maintenance in large companies. I completely stand by this. My problem with Scala, again, is not that it's a bad helicopter, but that it insists that it's a good choice if what you want is a car (unless you actually try to drive it like a car -- as Spark does -- in which case you invite the ire of the entire community), and, IMO, it isn't.

6. It's OK to not like your language. It's OK to say it. It's OK to explain why. And it's OK for you to disagree. That doesn't make me biased, and certainly not some kind of bogeyman. It also doesn't justify ad hominem attacks, which -- unlike my criticism of Scala -- are completely unfounded.


Good points, as always.

> None of those features (except sealed ADTs, which really aren't necessary) is missing from Kotlin. The set of Scala features Spark is using is pretty much identical to Kotlin.

I didn't mention implicit conversions, but that's one area where Scala has taken the high risk high reward path. If you look a bit further down on the linked Spark page you'll see the conversions defined [1]. I'd say Spark's style guide is more geared toward Scala consumers and not necessarily library authors (i.e. if you know what you're doing have at it; otherwise keep to a strict subset).

Basically, in aggregate Scala's feature set is incredibly powerful; that power (despite the complexity, tooling challenges, and slow builds) is what draws dsl authors to Scala.

When IBM throws down an absolute boatload of cash on a project written in Scala, by proxy Scala benefits. Right off the bat there are de facto 3,500 new Scala developers (since the initial IBM Spark team will of course be learning Scala). Furthermore, it's not like competitors aren't aware of this, Spark automically becomes more of a "big deal" as a result, which cannot help but be a boon for Scala.

As for other JVM languages, agreed, Clojure has its own supply of awesome, though the lack of (built-in) static types are a no-op here. Groovy, meh, seems to be on a downtrend, I suspect non-immutable-by-default dynamic languages (except of course, javascript) will continue to fall out of favor.

Now, Kotlin, it's a nice language. If they can deliver on near Java build times, might just be the Java killer that Scala will never be, or at least not in its current design (where, as you rightly say, there is often more than one way to do the same thing).

Let's see how things play out over the next 3-5 years, JVM alternative language landscape is diverse and evolving quickly, good times now and great times ahead...

[1] https://github.com/apache/spark/blob/master/sql/catalyst/src...


> I didn't mention implicit conversions, but that's one area where Scala has taken the high risk high reward path.

We C++ veterans know that implicit conversions are one of the worst ideas to put in a language. They start simple enough and then they get clever, which is where trouble starts.

> i.e. if you know what you're doing have at it; otherwise keep to a strict subset

There are few things about programming language design we know, because getting empirical data is so hard. One of the few things we do know (from C++ in the nineties, of course) is that this kind of design doesn't work. The average codebase lifespan is about a decade, during which time people move around and team leads change. Everyone has their own discipline, and by year 5 (usually earlier), the codebase is unmaintainable.

Of course, now that C++ has been re-branded and re-purposed as a specialized language for close-to-hardware software, and is used by specialists, it is doing quite well. I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists (although even specialists would be better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea).

There is absolutely no reason to be as multi-paradigm as Scala is on the most polyglot platform around, which brings me to:

> that power... is what draws dsl authors to Scala.

One of the great things about the JVM is its relatively easy inter-language interop. I would use a meta-language made for DSLs (like Clojure, MPS or Xtext) for my DSL, while I'll write the infrastructure in Java/Kotlin. Learning Java and Clojure, or Kotlin and MPS, is easier than learning Scala alone (well enough for DSLs), and the results are cleaner, produce more maintainable code and better error messages (well, I wouldn't say Clojure excels at error messages, but at least the DSL writer has full control over them, and can make them quite good with an extra bit of effort).

Also, I'd like to see what those DSL codebases look like after five years of heavy usage (not to mention the error messages Scala spits out, which are completely unparsable to anyone who does not understand how the DSL is constructed).


> We C++ veterans know that implicit conversions are one of the worst ideas to put in a language

Too late to yank them now, can be disastrous in the wrong (read: beginner) hands, but they're fantistically useful in the dsl department so...

> The average codebase lifespan is about a decade

maintainability is an issue for the long haul, sure, Scala won't win that battle until it stabilizes, which is at minimum 3 years away when Dotty (Scala 3) comes on the scene.

> I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists

Typesafe does the marketing, and as a business they'll never sell their technology short, even if what you say is closer to the truth wrt to specialization.

> better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea

no users = no dice; doubt either will grab much mindshare in the near-term. Personally I would love to see SML cherry pick the non-crufty good parts of OCaml (including coming implicit parameters) and have that find a following outside of current tiny academic circle it languishes in.

> Also, I'd like to see what those DSL codebases look like after five years of heavy usage

They probably look a lot different than how they started out as...paraphrasing someone, "you're going to rewrite it [your application] at least 3X" ;-)

Basically the entire Scala ecosystem is a moving target, including the language itself. Enterprise outfits looking for a static dependency graph that will work today and 10 years from now should look at Java as the host language. I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle.


> Typesafe does the marketing, and as a business they'll never sell their technology short, even if what you say is closer to the truth wrt to specialization.

I don't think that's selling it short. Accurately describing your product only prevents people who aren't really your target -- like me -- from being disappointed and telling the world about it, while it helps attract precisely those people who would be most excited about it.

Also, I think Typesafe realize now that there is not much money to be made in developing and supporting a programming language (ironically, there is some to be made -- though not too much -- supporting specialist languages; see Ada and Matlab). That's why they want to change their name, right?

> no users = no dice; doubt either will grab much mindshare in the near-term.

That's splitting hairs a bit; Scala doesn't exactly have mass appeal either. We're talking about the difference between tiny and small.

> I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle.

I know they're trying to. Also, I know Oracle actively encourages alternative JVM languages. Their product is the Java platform, which currently -- to be honest -- is not too far from being the same as Java the language (all alternative JVM languages combined don't amount to 10%, or possibly even 5% of the JVM ecosystem). But they wouldn't mind if that changes. Their research team working on Graal, HotSpot's next-gen JIT, coming to OpenJDK in Java 9, spends as much time on making sure it runs Ruby, R, C, Python, and JavaScript well as it does on making sure it runs Java well. I know Oracle's Java team isn't all too happy about it, but I also know that that's what Oracle wants.


To add to my previous comment (now below), Scala DSLs are without rival only in the complexity of their composition. Clojure DSLs are based on macros. Groovy's are on builders and method-missing. Haskell's are on symbols, monad syntax (do) and lazy evaluation. Kotlin's are built with typesafe builders and inline functions. Scala's are built with symbols, right-associative operators, macros, implicits, monad syntax (for) and possibly even dynamics.

Even this most powerful yet most dangerously-clever capability offered by some programming language is supported by like five different Scala features with ten different ways of achieving the same goal. It's absolutely perfect if you want to explore different ways of programming. It's not so great if you need to maintain your DSL for the next 10-15 years in a large organization.

Besides, given that the JVM has two of most advanced meta-programming tools anywhere, Xtext[1] and JetBrains' own MPS[2], I wouldn't call any JVM language's embedded DSLs "without rival". All this is about to get even better with Truffle/Graal in Java 9. Saw an interesting talk about easily constructing very efficient languages with Truffle and object algebras at ECOOP[3]. So, especially on the JVM, going for an embedded DSL, let alone one built with very complicated techniques (rather than just Lisp macros) is probably not the best way to use DSLs. It has no advantages and lots of disadvantages.

[1]: https://eclipse.org/Xtext/

[2]: https://www.jetbrains.com/mps/

[3]: https://twitter.com/biboudis/status/618402989720662016


I very quickly skimmed through that scala style guide and starred it on Github, but having used both Kotlin and Scala, I am of the opinion that Kotlin (once it reaches v1.0) would remove the need for ~50% of the content of this style guide.


What is a pron? That's like a shrimp?


pron is the author of the GGGP post to the one you replied to.


Scala was our primary candidate, but there were issues back then, namely in terms of compiler performance and also tooling. Tooling isn't easy for Scala, and I believe compiler speed, Kotlin is already faster than Scala in terms. Also, we want to continue to provide support for JDK 6 thru 8.


There's still issues with Scala today.


I can't speak for JetBrains, but from my own experience with Java, Scala and Kotlin, Java interop in Kotlin is a lot better. Scala also offers a lot more features than Kotlin, which is great for highly experienced programmers, but usually means having to subset Scala for mixed experience teams. Kotlin seems to strike a better balance in terms of approachability and expressiveness, and hence being better suited for teams of different experience levels.


Where would Clojure fit into this mix? How would its interop compare with Scala or Kotlin, as well as its performance?


Clojure's Java interop is smoother than Scala's, but not as seamless as Kotlin's. Kotlin is modern syntax for the same Java APIs and programming philosophy. Scala and Clojure are radically different languages (from Java as well as each other), for better or worse.

Kotlin is a modern Java-replacement, while Clojure and Scala have different strengths and weaknesses. That's not to say that you can't write many applications in any of the four languages, but the "feel" of the codebase would be completely different in Clojure or in Scala, while Kotlin would feel the same (but would be leaner).


Clojure devs don't seem to care about performance.

Just check how the JVM gets the blame for what is essentially Clojure initialization time.

There are some in the community trying to improve the situation, but those are kind of forks like Skummet.


> Clojure devs don't seem to care about performance.

Ridiculous. Clojure devs care a lot about performance. We just care more about correctness.


By "performance" I think you specifically mean "startup time."

I think there is a big difference between startup time and runtime performance. It is well-known and fully acknowledged by the Clojure community that starting up a Clojure environment and REPL takes a while. But are you also suggesting there is a problem with Clojure runtime performance?


I got that understanding given how performance improvements get postponed version after version. Apparently they will be coming on 1.8.


After the start time, In my testing, I have never seen Java code that's faster than it's commensurate Clojure code. I've seen the reverse.


OK, so did Kotlin really cut down your codebase, and by how much?


We've not converted entire code bases, but based on what we're doing and feedback from others, we could say roughly around 35% or so.


> be concise but still expressive, toolable, as fast as Java, easy ramp-up time, and very important, interoperable with all the existing code base we had

... and when you went to the Scala developers, they said "no, we aren't interested in such improvements at all, even if you implemented them yourself"?

Hard to imagine...


Was there a need to develop a Java IDE in Java to begin with? I can understand dog fooding by building IDE-primarily-for-lang in lang itself. But were there technical reasons?

Or maybe Java just was the best alternative [at the time].


It's worked out pretty well for them I'd say. Consider that any developer can write a plugin for it easily, that cannot segfault the entire app, and which runs on all the platforms the IDE supports. That's just one advantage. Higher productivity of feature development is probably another.

To see how things could have been different, look at Visual Studio which is still a 32 bit program even in 2015. Users of it complain that it simply can't load big projects without running out of RAM even if their computer has enough. The VS team says they aren't doing a 64 bit port because it's such a big code base and besides, their plugin model is fully native. And of course it's Windows only.


> Higher productivity of feature development is probably another.

So productive that they had to invent a new language for the JVM platform?


At the time (~2002?), I think Java was a very reasonable choice for an cross-platform IDE. As more programming language research and different programming paradigms continue to gain mainstream adoption, Java's emphasis on backwards compatibility and stability makes it a bit difficult to change some of the initial design decisions that Java started out. However, since Java is so mature with an even more mature eco-system and an incredible runtime specification (JVM), it made sense to build a modern day "blue collar" language that could be classified as "Java, if it started out today." With that in mind, and some of the same principles that Java was founded on, Kotlin delivers on this promise. IMHO, it is the only JVM language that really does bridge this gap.


They didn't have to - JetBrains has been around for a long time and Kotlin is new. The productivity benefits mostly come from things like fast compile times, garbage collection etc.


As a user of it, I appreciate that I've been able to use it on three different OS's with minimal adjustment, which Java facilitates more so than other languages, especially other languages which would be reasonable candidates for a thick-client application like this.


The three founders of JetBrains started a plugin named Renamer out of need, while working with Java code at TogetherSoft. That was over 15 years ago.


There's like 9000 programming languages. Not a single one was adequate?

Color me skeptical.


No it's more like 9000 implementations of the same programming language. Only those from academia have ever been new languages.


It seems that Kotlin was adequate, which is why they chose it. With no idea of the project or the team working on it, I'll assume good faith that they were right.


They didn't choose Kotlin; they created it. (Though, having looked into alt JVM langs recently, I agree that they probably made the right choice in creating something new).


Or yak shaving?

I remember reading comp.compilers for a long time and people would always post about creating the next great language. They first thing people (usually John Levine) would ask it, "Why does the world need yet another programming language?" Not necessarily to discourage, but to invoke thoughtfulness.

There's nothing wrong with new languages. But it seems people are popping them out left and right these days. I think Javascript frameworks are the only thing that come faster.

So, do we _really_ need yet another new programming language?

Down vote me all you want, but at least I ask the question.


Well, 99% of those are silly little "my first programming language" thingys, and these are easy (if you care about those things) to recognize and ignore. They invariably focus on syntax: removing the semicolon, or braces, or some other trivial thing along these lines. BTW even those can be useful for PL researchers as the language may have an interesting new idea or a new way of doing things. Highly unlikely, but does happen.

On the negative side, and this is really bad, some of these may be picked up simply because they are new, and then they just create negative value for people that pick them up (e.g. Coffescript) and fragmentation. Then they get abandoned because there is another newer thing. Sad.

Then there a languages made by people with background in creating viable (as in not-just-academic) languages. Typescript and Go comes to mind. These are good and "we" need them. These may add new features to the table, eg generics or union types or goroutines.

There is no easy answer to your question, my best answer is "depends on who made it".


Given the constraints we imposed on our decision, I'd say that number was quite lower.


This may provide some insight:

http://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-needs...

The nice thing about that post is that they (Jetbrains) are pretty honest about the whole things e.g.

"First and foremost, it’s about our own productivity."

"The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. "

"The final point is less obvious but still important: new programming languages is a topic that many people really enjoy talking about, and the first days that have passed since we’ve unveiled Kotlin prove that."

"And we’d like to reiterate that our work on Kotlin does not in any way affect our investment into other development tools, and in particular the Scala plugin. If you’re already happy with Scala and have no need for another new language, we’ll continue to do our best providing you with first-class Scala development tooling."


I have written Kotlin for an Android app now in production. Having written plenty of Java for Android, Kotlin is really good. It feels like Java in some ways, but helps you more than gets in your way. Nullable/non-null features crush NullPointerException, which are the most common and annoying type of run-time error, this is actually a very pragmatic feature for professional programming. Overall it's less verbose than Java. It's not hardcore on functional programming as Scala is, but adds some FP niceties with its standard library, allowing you to use map/filter/reduce/etc functions on Iterables, which matches very nicely with RxJava if your project is using that already. Also, lambdas make it easier to use RxJava. And IntelliJ IDEA's plugin for Kotlin has a button "Convert Java file to Kotlin", which does a fairly good conversion.

The problems I had with Kotlin are minimal. When converting a Java file to Kotlin, I got ClassNameException (I might not remember the name correctly), but you just need to clean and rebuild the project. Lack of support for multiple constructors of a class made me scratch my head, but they added this support in a recent version. Overall Kotlin is a better Java (in less radical ways than Scala). The reason it's feasible for Android is that its size is comparable to small libraries like Retrofit, while Scala is huge and building Android apps together with sbt has been a nightmare for many who tried.

The adoption issue is a chicken and egg problem: long-term viability depends on people adopting it, and people want to adopt tools reliable in the long-term. So just do it. Java sucks anyway, I would do anything not to write it.


Kotlin is what Java would have been if it had been designed today. It follows the same philosophy: emphasis on readability, familiarity and maintainability, with PL research and new paradigms being non-goals. It does not introduce new concepts that will revolutionize your development, opting instead to adopt a few well-proven features (null safety, data classes). It is very easy to learn, feels modern and fun. Kotlin offers only a minimal runtime library, instead focusing on making the Java libraries more fun to use. Compilation is fast, and performance is about identical to that of Java.

While other languages promise a huge productivity boost (though few deliver) at a high switching cost, using Kotlin is practically free. It interoperates with Java so smoothly that you can gradually transition by freely mixing Java and Kotlin files in the same package. Calling and passing objects from Kotlin to Java and vice-versa is nearly seamless.

IDE support is world-class, and Kotlin is the only language other than Java (AFAIK) that lets you use annotation processors, so you can make use of, say, Dagger's compile time verification of dependencies.

My favorite feature is smart casting. Inline functions are a poor-man's macros: powerful enough for many things, yet not too clever to be potentially confusing.

The only concerns are with adoption rates, and whether the evolutionary progress justifies a new language. I think that the extremely low switching costs make it at the very least worth a try. Why not start with a mixed Java/Kotlin project?


"Why not start with a mixed Java/Kotlin project?" Think that's a good idea. If you are missing AST transformations you can add Groovy to the game. All three languages in IntelliJ work really fine together. In eclipse you might have to rebuild the entire project when doing mixed language programming. I learned this were a problem with ecliupse, though.


I've been using Kotlin for about three months to develop an Android application that is now in production.

To be honest, I love it. Here's a comment I wrote a few days ago about my experience with it for Android development, from the perspective of someone coming from java:

"Seconding Kotlin coming from Java. It takes maybe 2 days to learn everything in the language if you already know Java, and it fixes pretty much all the warts that bother me about Java (the big ones for me are immutable references by default, first-class/higher-order functions, and unnullable-by-default references. Type inference and string interpolations are handy as well). It also has a small enough runtime/stdlib (unlike Scala or Clojure, which I've also tried) to make it practical to use in environments where startup time matters, specifically Android."

Compared to Scala, Kotlin is definitely less powerful. But there are three things that concern me about Scala: (1) really long compile times (2) a big runtime (problematic for Android development, although less of an issue on the server) and (3) a "the good parts" syndrome -- that is there are parts of the Scala standard library/common practices that everyone seems to agree are best to avoid. If Kotlin weren't around I think I would look to Scala as my go-to JVM language despite these issues, but given that Kotlin exists and gives me nearly all of the sugar I'd like from Scala without the pain, I'd rather develop in Kotlin.

I'm not particularly worried about the community size, although it would be wonderful if the language picked up steam. JetBrains has demonstrated a big long-term commitment to continued development, it's open source, and the Java interop is so seamless that the library ecosystem is a non-issue -- you can use code written in Java without even knowing the difference. And as dodyg says in another comment, the language is really small if you're coming from Java or C#, so there's not a lot of room for undefined or confusing behavior -- it's true that there really ought to be more documentation, but given how similar it is to other languages it should be pretty simple to translate code/examples from Java to Kotlin (IntelliJ even comes with an automatic Java -> Kotlin translator that just works).


Apparently Google used it for prototyping the new data bindings library in Android.

https://www.reddit.com/r/androiddev/comments/3egzq5/so_has_g...

For me the language looks nice as alternative to Java 6 on Android (or 7 when targeting 4.4 onwards), but those break@label, continue@label, .... put me off.


I'm surprised how often this comes up. What's the big deal with this syntax? It's not even used all that often, only in some special circumstances.


After reading Mike Hearn's article on the subject[1], I'm convinced. The next project where I'd normally reach for Java and where I have some freedom in choice of language, I'd pick Kotlin instead.

[1] https://medium.com/@octskyward/why-kotlin-is-my-next-program...


Well, let's look at the JVM landscape. First of all Oracle has (finally) picked up the pace in terms of evolving Java and the JVM.

This is a bit of a double edged sword for alternative JVM languages since on the one hand JVM improvements (like current SAMs and value types in Java 10) are a big win for all involved, but on the other, Java's evolution is very much a threat to Scala, Kotlin, and Ceylon in particular*

Why is Java's evolution a threat? As Java cherry picks functional idioms from, for example, Scala, the motivation for Java teams to pick up Scala is reduced. Arguably Kotlin is in a worse position as its main "problem" is being too similar to Java. Already Java has deprecated the `_` character so shouldn't be any surprise to see `roster.stream().filter(_.getGender() == Person.Sex.MALE)`, land in the language [1]...getting pretty Scala-like o_O

Kotlin's window of opportunity is in the next 2-3 years, basically before Java 10 lands. If an ecosystem develops around it (likely one of the reasons adoption rates are so low at present) and their 1.0 comes on the scene soon, they can steal some limelight from Scala, and maybe put Ceylon in the rear view mirror.

* Clojure and JRuby are probably safe given their non-Java roots, and Groovy, not sure where it would be without Gradle.

[1] https://docs.oracle.com/javase/tutorial/collections/streams/


I find it highly unlikely that java would adopt the implicit lambdas using underscores from Scala. The rules regarding precedence themselves are quite simple, but they're not always what new users expect, and cause too much confusion to be appropriate in java. Much more likely is the use of the underscore as an anonymous placeholder in pattern matching. Although even full pattern matching seems a bit much for java in the near future. Pattern matching is more useful than implicit lambdas anyway, the latter being nothing more than a terser syntax for regular lambda expressions to approach the concision of Haskell's point free style without leading to code that's too semantically dense. Pattern matching actually makes new kinds of static guarantees possible.


> I find it highly unlikely that java would adopt the implicit lambdas using underscores from Scala

Looks like you're right [1], see Goetz's comment in linked thread. Though that was 2 years ago, the language landscape has changed (notably Swift's arrival and M$ setting up shop on *nix) so Oracle may be a bit more willing to pull the trigger on some easy syntactic sugar to give Java the impression of being somewhat up-to-date with current languages. Underscore is earmarked for something regardless, we'll see..

[1] http://mail.openjdk.java.net/pipermail/lambda-dev/2013-Augus...


I doubt it. Java 10 is very, very unlikely to match even a fraction of the features Kotlin has. Oracle is very obviously continuing Sun's strategy of focusing on the JVM rather than the Java language.

Their roadmap is pretty clear for the coming years, and it's all things like value types, better arrays, better APIs, modularity, performance, better ways to do "unsafe" stuff, etc. The only major change to the Java language they seem to be exploring right now is improved generics/class specialisation, and only because that's needed for the value types project.

Kotlin has basic things like real properties, which Java still lacks after two decades. Along with many other features.

The big competitors for Kotlin are Scala and Ceylon.


> Oracle is very obviously continuing Sun's strategy of focusing on the JVM rather than the Java language.

Absolutely. Oracle's strategy is very simple: Java should serve as the assembly language for the server side. The JVM should be the de-facto runtime. Like pron suggests, they are actively encouraging alternative JVM languages and I wouldn't be surprised if they invest in the JRuby/Jython implementations for quicker adoption.

As someone watching from the side, Oracle's strategy is brilliant.


Oracle has been investing significant resources in JRuby for some time via the Graal/Truffle research projects. They're quite impressive.


Plus Oracle is actively encouraging alternative JVM languages.


In clr land we've already seen c# adopting a fair few functional things - I think largely ahead of Java. There's this pretty interesting article from an f# (if anyone's unaware that's a Microsoft built functional language on the clr) tutorial site addressing reasons to still use f# over it. It's quite opinionated but worth a read and largely applies to Java/functional on the jvm: http://fsharpforfunandprofit.com/posts/is-your-language-unre...

They take a different view to the comparison, looking at things the language enforces more than features/syntax it permits. Of course backward compatibility and plain sanity stop Java making such enforcements so the argument is that the functional languages maintain some strong advantages.


There is a Haskell implementation for the JVM if you want a language like F# (it's called Frege).

Kotlin has some FP features. You can easily make immutable data classes (one line definitions of struct like things), you have map/filter/reduce/etc with a much more efficient approach than Java 8's streams framework, the compiler knows about tail recursion, there's some basic forms of pattern matching.

I suspect Kotlin will take a breather from new features for a while now to try and stabilise what they've got. But after that, I imagine a few more FP features might materialise.


And there's a very good implementation of OCaml for the JVM: http://www.ocamljava.org/


Sorry, I think I was a bit unclear. I have no doubt the jvm can support a functional language - scala isn't bad and Kotlin looks really nice. My point is more that Java is constrained in how it can compete with functional jvm languages in much the same way c# is against functional clr ones. The linked article explains those limits a lot better than I could :)


Ah, I see. Yes I misunderstood you, apologies.


> Groovy, not sure where it would be without Gradle

Gradle's bound to open up its build configuration as an API that any scripting language can use soon enough, so not sure where Groovy will be then as Android Studio ships Gradle with another default build language like JRuby, Jython, or even Clojure.


I don't think any new additions to Java will threaten Clojure. Worst comes to worst, I see Clojure moving off the JVM if the platform becomes untenable in the future, though there's nothing to indicate that it would.


We built Roll for Android ( http://tryroll.com ) in Kotlin -- we currently have ~17k lines and have been working on it since this Spring.

We wanted to iterate on a lot of the software structure we came up with for our Swift iOS app, and for a bunch of pieces we needed a powerful type system. So rather than just stick with Java -- as others have said, it's way too verbose, we started looking at alternatives. We wanted a strong type system. Scala has too much overhead for Android. Kotlin really stood out for us. This document by Jake Wharton at Square https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhC... made the decision easier. So we took the risk.

And we love it!

The best features:

Null type safety!

Lambdas can be inlined! No need to be afraid of anonymous inner class overhead on the map/filter/fold of iterables.

Reified generics!

Extension functions!

Single-method interfaces/classes can be represented as lambdas! aka

  view.setOnClickListener(new View.OnClickListener() {
     @Override public void onClick(View v) { /* do something */ }
  });
becomes

  view.setOnClickListener { /* do something */ }
This is great for things like RxJava.

Speaking of which, the Java interoperability is fantastic. Any Android libraries we've tried work great from Kotlin.

Using these tools, we've built a simple dependency injection framework, a handful of really useful extensions on things like T? (for example monadic bind), a hack for algebraic data types and pattern matching, and of course a fairly complex app.

Android Studio's Kotlin support is fantastic (good job JetBrains!) -- it's a pleasure to use.

I think Kotlin is totally worth using. The biggest issue for us is the build time. Our build takes anywhere from 1.5 to 6 minutes depending on how much you've changed, but I've found that the type system is strong enough that you don't have to do too many build-change a line-rebuild cycles.

We'll be starting a blog soon to talk about some of the stuff we've been doing, but if you can't wait send me a message bkase at highlig.ht if you're interested in hearing more (I love talking about this stuff)


Lambda inlining only works for very narrow scenarios. Passing a lambda to any Java API, such as event handlers in Android, will always have to resort to an anonymous class translation strategy, which generates a static or instance method in the outer class and a lambda class implementing the functional interface, forwarding to the outer class method. Non-capturing lambdas can be instantiated once and cached statically, forwarding to an outer class static method. Capturing lambdas can not be cached but still forward to an outer class static method. Lambdas capturing fields of the outer class can also not be cached and need to forward to an instance method of the outer class. Many lambdas passed to Android APIs will result in the last translation scheme.


Thanks for the info! I did know that passing lambdas to Java API calls still has to instantiate an anonymous inner class, but the details about what happens in each situation are new to me (and really interesting).

I'm sorry that I didn't make it clearer in my post (I'll edit it), but the thing I really appreciate is that I can use functional methods on objects (like map, fold, filter on iterables or our monadic bind method on optionals) and pass lambdas because I know it will be inlined. The inlining -- which should always happen this particular scenario (please correct me if I'm wrong) -- makes using these methods super cheap!


Only a look at the resulting bytecode will tell you what happens in your scenarios :)


No need for bytecode when a stacktrace will do :-)

    public static void main(String... args) {
        Runnable r = () -> {
            ((Object)null).toString(); // kaboom
        };
        r.run();
    }


Kotlin is great, but I would like to point out a few things:

> Lambdas can be inlined!

Kotlin's inline functions are meant to serve as a poor man's macro system (to implement simple control structures) and/or for argument type specialization -- not to save the "inner class overhead" because, guess what? There isn't one! While HotSpot's JIT will certainly not inline lambdas in every circumstance (though it's getting better), it will inline them in all cases where Kotlin's inline functions can be used (and many others where they can't). It is possible, however, that inner classes do have some overhead on Android.

> Reified generics!

Kotlin does not reify generics, and like in Java, that's a good thing! Java's erased generics are precisely what makes polyglot interop easy.


I haven't looked into it much in the past few years so it is possible the inner class overhead on Android is not significant anymore, but a few years ago it was definitely something to watch out for on Dalvik.

Again I wasn't being very clear, sorry about that: Kotlin doesn't always reify generics, but it can for functions you mark as inline if you want (it's useful!). Check out the inline function docs!


Inlining is also about performance. Classes impose significant memory and code size overhead even if HotSpot does inline the code eventually .... but much code is still interpreted. And Kotlin also targets Android. Finding documentation about what optimisations ART does is difficult, but I imagine it's got a weaker compiler than HotSpot if only because it's newer.


Not directly related, but for completeness sake: Java 8 lambdas only generate classes for capturing lambdas, and even then, only at runtime (a class file isn't generated). Kotlin can't quite do that because it relies on method handles and invokedynamic, which are missing from Android.

Also, there are few compilers anywhere with optimizations as powerful as HotSpot :) And HotSpot compilation is only getting better and better. Java 9 will even let us use Graal as the optimizing compiler (i.e. instead of C2), which can do this: https://twitter.com/ChrisGSeaton/status/619885182104043520


Your comment on build speed is interesting. Do you have a ballpark figure for Kotlin compile speed in lines per minute?


Kotlin is not actually slow to compile. The problem is that incremental compilation and gradle/android don't mix. So it ends up recompiling the whole thing each time.

I use Kotlin for non-Android projects with Maven, so incremental compilation works. Build times are not a significant issue, though the Kotlin compiler is still not as fast as the Java compiler is. I noticed from doing hotswaps when debugging processes that Kotlin seems to still compile too much, even when in incremental model. So I hope once JetBrains get stability under control they can spend some time optimising.


Unfortunately, not. We had a bad gradle config for a while so when we fixed that our build time jumped down from 6min incremental to 2min. However, I can tell you that I haven't noticed an increase in build time since we fixed our gradle settings which happened a few months ago and we have added code. Maybe it's a function of gradle modules (we have around 25)? If we ever spend a bunch more time trying to optimize our build time we'll write about it somewhere.


That single-method lambda thing I'd really good to hear. Most of my java code is just gluing together APIs, so lambdas don't do much for me unless I can use them with naive java APIs.


Mail to bkase at highlig.ht bounced back. Are you sure the mail address is correct?


I have used it for a small amount of production code in a mixed Java / Groovy codebase coded using Intellij and Kotlin version 0.11.

Kotlin worked well - clear concise code, no null worries and no cast worries.

It is peculiarly refreshing to know that my code won't even compile if I try to call a method on null and that Intellij will underline the code in red and suggest a fix.

At the time I was using it I would say the quality of some of the code in the Kotlin API was questionable - specifically the jdbc code. I used the parts that seemed sensible and wrote additional code to provide the functionality I needed. I don't think that code is even in the standard API anymore.


> I have used it for a small amount of production code in a mixed Java / Groovy codebase

Hope first priority was to replace the Groovy rather than the Java.


Yes, I've used kotlin to replace a large legacy Java application. Pretty critical to the business, sat in the middle interacting with. All upstream and downstream systems.

Kotlin certain ly made life easier in some places, most importantly it was fast and easy and a joy to work with.


How can I contact you to hear more about your experiences?


pm me :)


It seems that Kotlin will be officially presented as next language for Android. IDEA and Android Studio will receive built-in full support for Kotlin in nearest future.

I write some parts of Telegram app in Kotlin. Pretty good after plain java. I can't rely on it in production yet (used in build chain).

My feelings that React Native + Kotlin could be awesome combination.


"It seems that Kotlin will be officially presented as next language for Android."

Source?


it seems they've already started playing with it https://twitter.com/rosshambrick/status/624431306567385088


Just rumours. I hear that Kotlin will be preinstalled in nearest versions of Android Studio.

For google Kotlin can be very good language: it designed to compile to javascript, so you can write code for Android and Web in one language.

Also JetBrains developing (not a surprise) Android Studio for Google. JetBrains is most qualified company for building Java-based language.


Are you referring to Android Studio or IntelliJ IDEA? We will be shipping Kotlin bundled in IntelliJ IDEA 15. Regarding Android Studio, we don't develop Android Studio for Google. Google does. We develop IntelliJ IDEA Community Edition, which is the base on which Android Studio is built.


I've been using Kotlin on-and-off as a Java replacement and I've really enjoyed it.

A couple of months ago I used Kotlin to setup a Dropwizard project and it was a breeze so I put together an example on GitHub to serve as a starting point for others: https://github.com/doomspork/kotlin-dropwizard


Need more projects like this! Thank you!


You're welcome!


Another language you may want to look at is Ceylon from RedHat, which has some interesting features (union and intersection types, notably)


https://plugins.jetbrains.com/search/index?pr=idea&search=ce...

Everyone and their cousin can create a language, but without tooling then one is back to authoring in "dumb" editors and I will never ever tolerate that on a team again.


I today decided to try it on small project. I had a lot of class name clashes (wsimport from similar but different WSDLs). I had a nightmare in Java and Kotlin saved me, thanks to its smart import. Properties are much more readable than getters-setters. And there are a lot of sugar here and there, which makes programming more fun.

I literally spent may be 5 minutes reading their site. The language is extremely small and intuitive to pick up, if you had some experience with Scala.

IDE worked fine. I had few exceptions, but they didn't ruined anything. Refactorings worked. IDE support is very nice.


I had never heard of Kotlin but after looking at the docs I am very impressed. I spend most of my time in the web development world (PHP, Javascript) but I am thinking about starting a small Android project.

I have zero Java knowledge so I wonder if it is feasible to jump straight into using Kotlin or to try and learn some Java first?


If you want to leverage the whole 100% interoperability of Java (which is a HUGE selling point for Kotlin), I think knowing some Java will be extremely helpful. If you're starting a project from scratch, it might not be necessary if you're building on projects like dropwizard-kotlin, etc.


Knowing Java is quite helpful if you're building for the JVM, but if your target is JS, then its not much of a problem.


> I worry about its long term viability given it's low presence on GitHub[1] and < 40 users on #kotlin on Freenode IRC

It's only on version 0.12.213. Bit premature to judge long term viability imho.


The minor version represents a milestone, currently at 12 and each of these is considerable effort, in terms of decisions and implementation of language features (as well as tooling).


hhariri - maybe it might be time to get a (rough?) roadmap so that we can plan around it. I know JetBrains is shooting for Q4, but would still be good to track it.


I'm currently writing a book about Kotlin for Android Developers:https://leanpub.com/kotlin-for-android-developers

Overall I think it is a really interesting language for Android (and I guess Java) developers. It's much cleaner and safer. I recommend at least taking some time to play with it and see how it looks. I also have some simple articles at my blog, antonioleiva.com, very basic and perfect to start with it.


Link for clickability: http://antonioleiva.com


I toyed with Kotlin for Android development. It is very promising. It solves many of my annoyances with Java while keeping what is working.

I work in an 8 engineers Android team, switching to Kotlin for our Android app is not on the table at all though. Our huge codebase and complex build script can't be easily retuned to another language, even one compatible with Java and it is an added liability we don't want to deal with. If Google were to adopt it, it could very quickly gain steam for Android development.


Always looking for something more simple than (my current) Scala.

- Argued with the developers, they have not clue about Option/Maybe and what it's good for. They offer non-nullable type which solves just one - minor - problem with Null

- No deconstruction

- Their documentation in the beginning mixed features and planned features without discrimination. Spend a lot of time to find out trying to make them work that the features they've described in detail were fantasies.

- With deconstruction I would give it a try in a project.


The development team has always been very friendly and welcoming. I suspect that they didn't have time for someone who was interested in "arguing" with them.

Since Kotlin can leverage JVM libraries, why not use Google Gauva? https://code.google.com/p/guava-libraries/wiki/UsingAndAvoid...


I was not 'arguing with them' but when asked what was missing I offered deconstruction for nicely using Option/Maybe for which I was told there are non-nullable types. Rest see above.

I personally would listen instead of attacking me.


To clarify:

Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs.

Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.


The question is, why should this be part of the language or standard library? This can easily be achieved by a library.

The Kotlin type system does help though/is essential to correctly implement Option types where other languages like C# can not.

The essential part is you can/should define an Option type with a non-null upper bound. Otherwise you would have a Some() that still might contain a null value. So the side affect of solving NPEs you speak of is only there if a language actually supports non-null upper bounds.


Without proper Option deconstruction and map()/flatMap() syntacic sugar Option code beside map() is not very pleasent to read or understand to my eyes :-(


Non-nullable types aren't just about uninitialised vars, where did you get that idea? Consider that function parameters can also be nullable although you cannot help but initialise them. Nullable types (nonnull is the default) solve the issue of optionality: something that might be there sometimes but also may not be.


This is hard to explain and I didn't understand it either, after programming Java for 15 years. After 5 years of Scala I can't think of not using Option.

If you allow null as a return type you need to check for null if you want to use it or not. If you return Option[_] people e.g. just use map() on the return value and then map().map().map().map() on that etc. With Option your code usually does not care to check until the very last moment. Sorry my English is not good enough to make the point :-( And I know, saying "You need to use Option (and Applictives etc.) some years to grok" sounds arrogant and unsatisfactory. But I would not go back to a language without Option (and Applicatives etc.) usage in it's culture.


In Kotlin there's a bunch of null-handling operators, which allows you to really treat null as None. Like x?.y()?.z(). Moreover, you can define extension functions on nullable types, which covers Option's map and much more.


How is option different from proper nullability in the type system? In every case I've seen an option type be used, it was always a less efficient way of approximating how Kotlin does it.

Kotlin has deconstruction:

    val (a,b,c) = myDataObject
Their documentation did indeed commit this sin when I first started using Kotlin last year. It's been cleaned up considerably and this is no longer an issue (except, I think, for the mysterious modules which appear to be an IDE specific concept).


1. Option solves a long list of programming problems (mostly around things being there or not, but others as well) while non-nullable types only solve NPEs.

2. Sorry, wording is vaque, often deconstruction is

val MyValueObject(a,b,c) = myObject


I used it for a small Android project while AndroidStudio was still in beta. Had some minor hickups but it got better with every small upgrade. I was really happy to use it, it's a nice language, actually it was fun to use. When I didn't want to use the documentation I just wrote the code in Java and let the IDE translate that to Kotlin. Two things I liked the most: Null type safety and you don't need to catch every exception if you don't like.


I have been using Kotlin in production for 2 Android apps since october 2013.

It made things simpler to write, develop and maintain.

One big downside, as of 0.12.1218, is that builds on Android are quite slow (I got 5min builds). But the Kotlin team is aware of the issue and working on it.

Once the kotlin builds on Android get fast enough, it will blow everything else out of the water.

If Google were to switch from Java to Kotlin for android, I wonder how Oracle would feel...


I started looking into Kotlin already when it was M2. Always liked it a lot, because every feature has a reason to exist. Nothing is added without careful thought whether it is needed at all or could be solved in the library anyway. Scala would have been a much more consistent language if the Scala people had progressed in this way as well and Scala code would also be much easier to read.

Kotlin seems to have a killer feature which is Android development, which is of course good. But what about internal enterprise development? It makes me think whether Kotlin has enough added value to make people change from a safe haven like Java8 to Kotlin. Sure, much better build times and less problems with code readability when using Akka, Play, Spark with Kotlin instead of Scala. Also Kotlin offers much more power in exploiting the features of those tools compared to Java. But how many people use Akka or Spark? Nevertheless, I wish Kotlin all the best. I will always greatly prefer it over Java or Scala.


It is officially supported by Jetbrains. I don't really see it as a full-fledged language but rather an extension of Java. I'm planning on trying out on my next Android app.


In what sense don't you view it as full-fledged?


Java interop is a "first-class" citizen, even more so than say Scala.


The same can be said for Clojure, but I haven't met anyone that would claim Clojure is not a "full-fledged" language. Interop has always been one feature, of many, that languages do or don't have (e.g. C++ interop with C, or C with Assembly).


But how's that making it less fully-fledged? Actually maybe I should first ask what you mean by full-fledged :)


How does Kotlin compare to Ceylon? Has anyone written something in both languages and can share their impression?


Kotlin is build with interoperability with Java in mind from the beginning. This is not the case in Ceylon. In fact some base types (Int, Long) in Ceylon don't match the corresponding Java type. Kotlin has extension methods which Ceylon has not. Ceylon has reified types, which Kotlin has not. Ceylon went 1.0 in November 2013. So far Ceylon seems not have caught any traction, which is unfortunate as it also is a language well-made in many ways. Kotlin has at least Android development to create some initial traction.


Quite similar in terms of feature-sets, but I would say Kotlin has better tooling and Ceylon has better documentation, and tutorials.


I wrote a small implementation of ListView in Kotlin a while back just to try it out [1]. The pros are pretty cool and some of the issues I mentioned in the readme have been fixed now (multiple constructors).

There are still a couple of issues though:

- Debugger functionality in IDEA (maybe it's been fixed now?). It was pretty unusable last I tried.

- (Android-specific) When extending Android framework classes you don't gain much benefit, since you'll be using the !! operator (override null-safety) a lot, and you'll be somewhat forced into a design pattern that takes away a lot of the power Kotlin offers.

If I were to use Kotlin, I'd use it for helper classes and extend View classes, etc. in plain old Java.

[1] https://github.com/T-Spoon/Kotlist


I've played a bit with Kotlin and have a much better knowledge of Scala, so I could be biased. I like Kotlin, it looks like Java should look like. Kotlin is "just" a better language and not a complete new World like Scala. In Scala it feels often wrong to use a Java lib instead of a Scala lib. So, Kotlin is a smooth upgrade for all Java developers.

But Scala is much, much more powerful than Kotlin. Just look at Scala Traits for example. I think, if you have good developers who are willing to learn and to improve, you can get more out of Scala. If you're not that lucky (and I think that is the usual case), you maybe better off with Kotlin.


Traits seem like an odd feature to pick. What are you thinking of, precisely? Kotlin interfaces are basically the same: they can contain method and property impls (same as Java 8). Do Scala traits have some additional feature I am unaware of?

I admit to a little bias: I've tried to get into Scala several times, but the bad documentation and often overly complex approach puts me off. A lot of Scala features seem like workarounds for other features sometimes. For instance value types in Scala have so many restrictions that they are barely value types at all (e.g. they can have only one member!) and so their primary use case appears to be implementing overhead free extension methods. But Kotlin supports extension methods directly. So whilst implicits+value types may appear to be two features that Kotlin lacks, when you boil it down, it turns out that it has simpler and faster approaches to the same thing.

That said, real value classes (with JVM support) will be good when they arrive.


Kotlin interfaces are essentially the same as Java interfaces. But Traits in Scala are more like (slightly) restricted multiple inheritance. They can have fields, they can be stacked (http://www.artima.com/scalazine/articles/stackable_trait_pat...), you can restrict the types where a trait can be mixed in.

Value types are useful to enforce certain types which helps to avoid million dollar mistakes like the NASA made when mixing inch and meter as simple floating point numbers.

All in all I think, that Kotlin is a good example of the 80:20 rule. You get the most useful concepts and convenience with a low investment. Maybe Kotlin hits a sweet spot in the JVM landscape.


"Kotlin interfaces are essentially the same as Java interfaces." Interfaces in Kotlin offer functionality beyond interfaces in Java. In Java interfaces can only have public methods. In Kotlin interfaces can also have (abstract) variables. Both, methods and vars, in Kotlin interfaces can be public and also protected. You need this if you don't want to break the encapsulation of your classes that implement an interface.


Yes, being able to define numeric units is a helpful feature indeed.


I think you are missing the motivation behind some of these things:

Oracle would probably never have started to experiment with value types and specialized generics, if Scala didn't take the plunge and implemented, tested and shipped it years ago already.

Of course there are restrictions... but the choice was basically either never getting value types and generics, or accepting some restrictions until Scala drags Java into the 1990ies.

It's the same with extension methods. If the only thing you ever knew where extension methods, they would look pretty exciting. But after being aware of the full range of approaches, extension methods are "meh" ... they only implement the least useful part of implicits.

If I had to decide between extension methods and nothing, I'd pick nothing. Extension methods are just not pulling their weight.

Scala does a lot of things in a certain way, because the have > 10 years of experience experimenting with various approaches.

I suggest that you try to understand _why_ Scala does things this way, instead of assuming Scala devs are stupid. It's pretty likely that everything Kotlin does has been considered by Scala developers 5 years ago already–and discarded because better designs were discovered.


We're developing out Android app in Kotlin! It is a very promising language and as others have mentioned, the IDE support is superb, first class. Easy learning curve if you already know another language.

And since Kotlin also compiles to JS, we're writing our REST api client in it so that our Android app and web product can somewhat share the same codebase.

I think Kotlin can potentially go mainstream


In my team, we are currently developing native Android app with Kotlin. At first, I wasn't sure it was going to be successful but when I looked back it was the best decision ever made to my team. Kotlin is short, concise yet powerful. Lambda, and extension are the best features. You can design your API interface in the most expressive way. It help makes communication between objects much much easier.

For Android development, it is even sweeter, who likes keep using `findViewById()`. Kotlin-Android-Extension does that automagically.

I even write my own HTTP lib for Android entirely in Kotlin. If you like to check it out, here it is (https://github.com/kittinunf/Fuel)


I tried Kotlin ~2 years ago and generally liked it. However, one thing that I missed is the possibility to generate Javadoc besides KDoc. This would be useful when writing a library in Kotlin to Java developers who are 'not in the know'. Any idea if this is possible now?


Actually this is being worked on right now: https://github.com/orangy/dokka/pull/32


That is a very cool idea.


After reading this and seeing some Jetbrains blog posts about Kotlin before, I decided to try it out.

I downloaded Intellij IDEA Community Edition, and with Java 7 already installed on my machine (OS X 10.10 - I use Java for RubyMine support), I went through the tutorial here: Getting Started with IntelliJ IDEA - http://kotlinlang.org/docs/tutorials/getting-started.html

I started at about 12:55 (download time in Firefox d/l mgr says Intellij d/l completed at 12:58). It's currently 2:13. So ~1h 20m later.

Some notes:

- First thing I did was install IDEA and then install the Kotlin plugin in IDEA.

- Next was creating my first project.

- Had to let IDEA know that I have a JDK when creating the project. Took me some time to understand. Once I added this I was able to create a Java project.

- The tutorial references creating a Java Module but I didn't know what that meant (still don't really, just know that I had to pick Java from the lefthand-side of the New Project window, and nowhere on my screen is Java Module mentioned). I checked off Kotlin in the Additional Libraries and Frameworks box and off I went.

- Also in creating a project, I get an error message that the library I'm specifying doesn't exist, but this doesn't seem to break anything so I ignore it.

- Every time I open a project in Intellij I get an error message: "IDE Internal Error occurred. Click to see details and submit a bug report." I click to see the details but the error message just disappears and it seems like there's no actual error at this point, stuff just continues to work.

- screenshots are out of date or else different for Community Edition. The wizard doesn't have the "Create Kotlin Library" popups, but some balloons pop up on the top righthand-side and allow me to do the same thing, I think, copying some jars into my project's `lib` directory.

- personally I find it slightly confusing that the tutorial asks for the file to be named `app` (as in `app.kt`), and would have preferred if it was called `hello.kt`, but maybe this is some kind of Kotlin convention, so I went with it.

- having created the project and the `app` Kotlin source code file, creating the Hello World program was easy and ran as shown in the tutorial.

- I did one bit of cleanup in here: I accidentally named my module folder "HellowWorld" instead of "HelloWorld" (though I think the tutorial screenshots reference plain-old "kotlin") and I poked around in IDEA for a few minutes trying to rename it. I couldn't see how, without possibly screwing things up or having to change a few path names. Being worried I'd miss some, I closed the project and renamed the directory in Terminal, and was able to open it up successfully again in IDEA.

So now I was finished the Getting Started with IntelliJ IDEA tutorial. I decided to proceed but it was a little bit unclear where I was supposed to go. I would have liked to see a suggested next page link on the bottom of the tutorial, but after clicking around I ended up on the Kotlin Koans page - http://kotlinlang.org/docs/tutorials/koans.html .

So I followed the Koan tutorial and it asked me to do a git clone of the Koan repo. I did that and opened the directory as a project in IDEA. `ls -l` shows me that the modified time on the koans dir is `25 Jul 01:21`. I believe that's actually the creation time (which is what I want, anyway, so you can see how my progress is going) since I have been modifying stuff up to the point that I wrote this post. (It's now 2:33, btw.)

The basic concept of the Koan tutorial is that a bunch of pre-written tests fail and you have to make them pass, one by one.

- I was able to run the tests and I find it a bit confusing where I can accidentally switch between running a single test or a whole test file, but I guess that's my inexperience with IDEA showing.

- the git repo dir is named `workshop-jb` -- I don't know what this means, but I'd prefer it to be named `koans`

- I've finished up-to-and-including `_4_String_Templates` so far, i.e. 4 directories worth of tests.

- I haven't yet referenced the `resolutions` branch of the repo, which the tutorial page tells me contains solutions to making all the tests pass. I figured I'd learn more by solving them on my own first. Maybe at some point I'll go back and take a look at the reference solutions.

- Running the tests and seeing them fail prints out some help messages about how to make the tests pass. I have found it a little bit confusing navigating back and forth between the reference code they show you at the top of the Koan file that the test executes, the example Java code they sometimes tell you to reference/convert to Kotlin, and the test. In the first, second, and third case, I found the reference code to be confusing -- I couldn't quite tell how it was supposed to help me pass the tests. In all four cases I found making the tests pass to actually end up being quite simple, but I was intimidated by the blob of reference code at the top of the `.kt` file and wasn't always sure what exactly I was to take away from it. I think it is definitely possible to trim these reference bits down and make them very specifically relevant to fixing the tests. I think they are trying to introduce a lot of features of the language at the same time as giving you what you need to pass the tests, and I find it a bit overwhelming.

- I've made a few attempts to read through the Reference documentation (http://kotlinlang.org/docs/reference/) and it looks interesting, but ultimately I don't think it helped me to make the test pass at all. I am not sure when/where I'd use it, but it did help me understand one of the labelled break/return comments that is posted somewhere in this comment thread. (Personally, I think that's a cool feature. I first encountered it in uC++ - http://plg.uwaterloo.ca/usystem/uC++.html .)

- Last thought: build times are IMO quite slow. I'm changing exactly one short file and it takes several seconds to run the new code, most of the IDEA status seeming to be in the "make" step of the process.

Ok, I guess those are my full thoughts for now, I am sorry if this brain dump was too long but I figured someone might get some benefit out of it. For reference, I've been programming for ~20 years now and I was only able to really get started when I first read one of my all-time favorite programming books, C for Dummies :) I was a DOS-fluent 13-year old at the time, and I'd tried reading some others and found them impenetrable. I think the ease of reading and trying shit out and the humor that I found in that book shaped my tastes for learning considerably, and while I don't think every programming tutorial has to be as gentle an introduction as that book was, I think it has a lot to be learned from in terms of programming writing. It's now 2:46. I am tired and going to bed!


Your brain dump is fantastic feedback for us. Can really help us improve the getting started and docs. Thanks for this!


I certainly recognize some of these pain points :) the need to register JDKs is not presented in a manner that's easy to understand.

Then there's the warning about unregistered VCS roots. I confess that rather than looking into the meaning of this warning and trying to fix it, I just uninstall the VCS plugin (git in my case) and do revision control outside of IDEA (TortoiseGit).


You're welcome :) Glad to be of service.


It was awesome 1 year ago and I think I it supports annotations now, so I'd go for it.


I've written an Android game in Kotlin:

https://www.youtube.com/watch?v=rISBeabXhvM


Evaluated it but decided to go with C# because it didn't fix a few issues i have with java, specifically generics over value types and structs.


Sadly, this is true. C# is just a superior language. The CLR though is arguably an inferior runtime when compared to the JVM -- maybe it'll catch up.


There are some people on Livecoding.tv programming in Kotlin. Which project are you thinking of building in Kotlin?


Where's Kotlin?


Kotlin is in the kitchen! (with Bryan)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: