
Ask HN: Has anyone here programmed in Kotlin? What do you think about it? - lemevi
I was looking at Kotlin and was curious. It looks very interesting feature wise but I worry about its long term viability given it&#x27;s low presence on GitHub[1] and &lt; 40 users on #kotlin on Freenode IRC. Is this worth writing a big project in?<p>[1] https:&#x2F;&#x2F;github.com&#x2F;search?o=desc&amp;q=language%3AKotlin&amp;ref=searchresults&amp;s=stars&amp;type=Repositories&amp;utf8=
======
dodyg
I started an open source Android project in Kotlin
([https://github.com/dodyg](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.

~~~
octocoupler
What is the 'swift syndrome'?

~~~
J0-onas
Im guessing making somwhat radical decision that are not backwards compatible.

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

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

------
gamesbrainiac
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](http://nafiulis.me/kotlin-
koans-i.html)

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

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

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

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

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

~~~
EdwardDiego
> 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?

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

~~~
lakedaemon
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)

~~~
mahmoudimus
> 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](https://github.com/puniverse/quasar))
so Parallel Universe can track this for a possible milestone?

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

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

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

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

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

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

[https://www.reddit.com/r/androiddev/comments/3egzq5/so_has_g...](https://www.reddit.com/r/androiddev/comments/3egzq5/so_has_google_started_using_kotlin/)

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.

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

------
rictic
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...](https://medium.com/@octskyward/why-kotlin-is-my-next-programming-
language-c25c001e26e3)

------
virtualwhys
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/](https://docs.oracle.com/javase/tutorial/collections/streams/)

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

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

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

------
bkase
We built Roll for Android ( [http://tryroll.com](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...](https://docs.google.com/document/d/1ReS3ep-
hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit?hl=en&forcehl=1#heading=h.v6i4iyf7kkxh)
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)

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

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

~~~
pron
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](https://twitter.com/ChrisGSeaton/status/619885182104043520)

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

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

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

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

~~~
steedsofwar
pm me :)

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

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

Source?

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

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

------
doomspork
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](https://github.com/doomspork/kotlin-dropwizard)

~~~
mahmoudimus
Need more projects like this! Thank you!

~~~
doomspork
You're welcome!

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

~~~
mdaniel
[https://plugins.jetbrains.com/search/index?pr=idea&search=ce...](https://plugins.jetbrains.com/search/index?pr=idea&search=ceylon)

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.

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

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

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

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

~~~
hhariri
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).

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

------
antonioleiva
I'm currently writing a book about Kotlin for Android
Developers:[https://leanpub.com/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.

~~~
mahmoudimus
Link for clickability: [http://antonioleiva.com](http://antonioleiva.com)

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

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

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

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

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

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

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

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

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

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

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

~~~
jballanc
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).

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

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

------
GeneralTspoon
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](https://github.com/T-Spoon/Kotlist)

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

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

~~~
cryptos
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...](http://www.artima.com/scalazine/articles/stackable_trait_pattern.html)),
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.

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

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

------
fkung
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](https://github.com/kittinunf/Fuel))

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

~~~
yole
Actually this is being worked on right now:
[https://github.com/orangy/dokka/pull/32](https://github.com/orangy/dokka/pull/32)

------
nchelluri
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](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](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/](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](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!

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

~~~
cmkrnl
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).

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

------
talloaktrees
I've written an Android game in Kotlin:

[https://www.youtube.com/watch?v=rISBeabXhvM](https://www.youtube.com/watch?v=rISBeabXhvM)

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

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

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

------
comrade1
Where's Kotlin?

~~~
Joky
Kotlin is in the kitchen! (with Bryan)

