
Kotlin 1.0 Released: Pragmatic Language for JVM and Android - belovrv
http://blog.jetbrains.com/kotlin/2016/02/kotlin-1-0-released-pragmatic-language-for-jvm-and-android/
======
norswap
I've been using Kotlin for work (I'm a PhD student, so work is to be
understood in a peculiar fashion) and I'm really liking it.

It's a much needed upgrade to Java whose fundamental advantage is what I'd
call "crispness": you can write terse code that is actually understandable. In
particular, the notion of inlining closures allows for efficient functional
programming and great DSLs.

In comparison to Scala, Kotlin is much less advanced, but much much simpler.
Like said earlier, it's easily as terse as Scala. Scala, however, is much more
expressive (what I'd give for typeclasses...) and that sometimes hurts in
Kotlin as it does in Java.

There's also Ceylon (JVM language by Red Hat) who is seemingly in the same
niche and which I very much wants to experiment with. From what I've read so
far, Ceylon seems conceptually more elegant and more powerful than Kotlin. The
open question is whether it can match Kotlin's crispness.

It feels a bit early for a release however. The compiler is still completely
wonky. Inference sometimes fails on things that should be completely trivial.
It is particularly bad at taking return types into account. It's fully usable,
but expect to work your way about some linguistic unpleasantness (or outright
bugs).

Also, for some reason, Kotlin seems big in Japan.

~~~
mike_hearn
By typeclasses, do you mean structural typing a.k.a. duck typing a.k.a. Go-
style interfaces?

I don't personally understand why people care about that: a simple structural
match on names/parameter types doesn't seem like a strong enough signal that
someone actually intended to implement such an interface.

But ... type classes can be implemented on the JVM relatively efficiently
these days. I threw together a simple Kotlin version a few weeks ago that let
you write something like:

    
    
       val foo = Foo()
       val bar = foo.dynamicCast<Bar>()
    

where Bar was an interface that Foo could have implemented but didn't. It
worked, but I didn't see any value in it for myself, and it didn't use the
latest JVM reflection APIs so it was slower than a normal interface call.

If there's some big population of people who really want this in Kotlin and
would be much happier if they had it, then I might sit down and reimplement it
on top of Remi Forax's proxy2 framework, which should give 1:1 native
performance.

~~~
lmm
No. Structural types are called structural types. The best known typeclass
implementation is that of Haskell where they're built into the language, but
Scala has them as a pattern implemented with implicits; I can try to explain
the concept here if you like but honestly there are probably better
explanations out there.

Typeclasses are more powerful than structural types in that the implementation
doesn't have to be there already (i.e. you can have an automatically resolved
adapter). You _might_ be able to hack an implementation by combining extension
methods with structural types (though given the internals of how extension
methods are usually implemented on the JVM I doubt it). They also allow a way
to do "static virtual methods" i.e. polymorphic methods that you don't need an
instance to invoke, which are used for things like Monoid#zero. Finally they
provide a nicer way to express F-bounded polymorphism (i.e. the constraint on
Enum or Comparable that we try to express in Java as Enum<E extends Enum<E>>
or Comparable<T extends Comparable<T>>, which is clunky and doesn't actually
fully constrain implementations the way it's intended to).

~~~
bad_user
> _The best known typeclass implementation is that of Haskell_

Oh, I don't know about that one. In Scala type-classes are interfaces and you
can put that OOP to good use. For example in the Cats library, you get an
Applicative type-class inheriting from Apply, a FlatMap inheriting from Apply
and a Monad inheriting from FlatMap and Applicative. By comparison in Haskell
a Monad is not automatically an Applicative and you get duplicate functions
with different names, duplicate code, duplicate tests, etc.

Another advantage is that in Scala type-class instances are actual values that
you can pass around. And because type-class instances are actual values, along
with implicits which are lexically scoped, you can always provide another
instance of a type-class, depending on context. You do not have the modularity
problems arising from usage of type-classes in Haskell.

" _The best implementation_ " is entirely subjective IMHO.

EDIT: got down-votes, not complaining, but I'd like to know where I'm
mistaken. Thanks.

~~~
koloron
Didn't downvote, just FYI: Haskell's Applicative is a superclass of Monad now.

~~~
Chattered
Which means you are now forced to write the boilerplate

pure = return

(<*>) = liftM2 ($)

In Scala, you get it for free for any monad.

~~~
koloron
Since GHC-7.10, the minimal complete definition for a Monad instance has been
(>>=) (bind) only. So you can simply move the old definition for "return" into
the Applicative instance as "pure" and you're good.

------
mahmoudimus
Congratulations to Andrey and the rest of the JetBrains team. This really has
been a long time coming. I've been following and experimenting with Kotlin now
for the past year or so and it definitely solves a lot of Java's pain points
without having to reinvent the way one thinks about programming languages.

The interoperability and backward compatibility is one of the most useful
features, meaning I don't have to wait for an entire ecosystem to develop
around it.

The tooling is also incredible and will only get better.

Concurrency support with Quasar and Comsat makes it relatively effortless
without reinventing new libraries.

Overall, Kotlin, IMHO, is one of those items in the "Pro"s section on any shop
seriously evaluating a JVM stack. Especially with Java9 on its way, it's only
going to get better.

~~~
azth
> Especially with Java9 on its way, it's only going to get better.

What's Java 9 going to add that Kotlin can benefit from?

~~~
pjmlp
Not much, other than VarHandles, JIT plugins and the overall JVM improvements
maybe.

The real juice will be in Java 10, assuming value types, proper generics, JNI
replacement and AOT support get delivered.

------
winterbe
Kotlin is currently my favorite alternative JVM language. Kudos to all
collaborators for the great work. After 5 years of hard work, you finally made
it!

Here's a little starter project for Kotlin webapps using Spring Boot and
React.js, I made a while ago:

[https://github.com/winterbe/spring-kotlin-react-
demo](https://github.com/winterbe/spring-kotlin-react-demo)

~~~
herval
My humble contribution to the hipster-stack-starter-pack:
[https://github.com/herval/gradle-kotlin-docker-
multiproject-...](https://github.com/herval/gradle-kotlin-docker-multiproject-
boilerplate) :-)

~~~
wcummings
>Building a JVM container with Docker. So you can put your interpreter inside
your JVM inside your Docker container inside your Kubernetes inside your VPS
inside your OS and be happy.

I want to cry.

~~~
easytiger
IT has to be satire right?

~~~
herval
yes, I tried my best to make it obviously satire...

------
zmmmmm
Kotlin sort of feels like Groovy "done properly" (with no disrespect to the
authors of Groovy). Groovy kind of evolved in an opportunistic, unplanned
manner and ended up with millions of features, cool whiz bang aspects that
look awesome that don't always turn out well when you use them on a large
scale. Kotlin seems to capture the same ideas (highly pragmatic, maintain
perfect bidirectional compatibility with Java), but done in a much more
thoughtful manner. Fingers crossed it works out.

~~~
lmm
I understand the author of Groovy said he'd never have started the language if
he'd known about Scala.

~~~
daviddumenil
"I can honestly say if someone had shown me the Programming in Scala book by
Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never
created Groovy."

[http://macstrac.blogspot.co.uk/2009/04/scala-as-long-term-
re...](http://macstrac.blogspot.co.uk/2009/04/scala-as-long-term-replacement-
for.html)

~~~
incepted
Shortly after saying that, he went on to work on the Kotlin libraries and
compiler (not any more, though).

------
mythz
Kotlin is a beautifully designed language: small, modern + statically typed
that's naturally terse and elegant - ideal for both OOP and LINQ-
like/functional programming:

[https://github.com/mythz/kotlin-linq-
examples](https://github.com/mythz/kotlin-linq-examples)

Thanks to JetBrain's tooling prowess it also has great integration with
Android Studio - Light years better for functional programming than Java 1.7:

[https://github.com/mythz/java-linq-examples](https://github.com/mythz/java-
linq-examples)

Which can seamlessly integrates with Java within the same project.
Google/Java/Android Devs are sitting on a unrealized gold-mine of productivity
with Kotlin, should be the modern successor for Android.

~~~
runT1ME
You're really comparing a small subset of what "LINQ-like functional
programming" is to the (small) pieces that Kotlin can do.

LINQ is _not_ (just) an interface over some collections. It is a comprehension
syntax (that kotlin doesn't have) that works on _any_ types that have
Select/SelectMany/Where.

This gives you a lot more power than what Kotlin gives you, as you can
'extend' other things that _don 't_ inherit from an IEnumerable<T>; for
instance Task or a custom data type that has its own inheritance hierarchy.

The 'comprehension' part means you can deeply nest things (similar to scala's
for compehension) without building up a stack of {}. This is quite common when
doing asynchronous programming, and Kotlin doesn't really help you out at all
here.

~~~
mythz
It's not a small subset, it's _the most popular subset_ that .NET developers
use LINQ for everyday as identified by _C# 's 101 LINQ Examples_ and compares
them against the equivalent code in Kotlin. The C# examples does use the LINQ
SQL-like DSL whereas other languages get by with a more readable and less
indirection version using functional API's available on collections. It's up
to the developer which they prefer however the LINQ DSL is no more powerful
than regular function chaining with lambdas.

LINQ also allows capturing Expression Trees however that's only useful for
developers creating LINQ providers or where they need to capture and
rewrite/reproject the expression. None of these examples are in the published
LINQ 101 examples as they're usefulness is limited to a small niche of use-
cases.

~~~
runT1ME
>languages get by with a more readable

I'd love to see how you think the kotlin (or java) version of the following
would be more 'readable'

    
    
         var result = 
             from a in taska
             from b in taskb
             from c in taskc(b) where c.Contains("blah")
           select c + a;

~~~
mythz
Again you're just cherry picking a rarely used niche example that benefits
from a SQL-like cross join, that you couldn't even map to a real-world
example. What's the point, to show it has terse syntax for rare use-cases?

Whilst the code is terse it's also deceptive as it's not obvious it's
performing a cross-join over multiple collections - so even in this case I'd
prefer using a nested maps which IMO is more readable as it's clearer what's
actually happening. Readability != terseness, it's clarity of intent.

~~~
runT1ME
>Whilst the code is terse it's also deceptive as it's not obvious it's
performing a cross-join over multiple collections - so even in this case I'd
prefer using a nested maps which IMO is more readable as it's clearer what's
actually happening. Readability != terseness, it's clarity of intent.

It has nothing to do with SQL cross joins across multiple collections.

LINQ is useful for things that aren't even collections! In my example I was
using them on a Task<T> to represent an asynchronous computation. This is
common code we would write in a large C# application I was on at my previous
job.

~~~
ufmace
It's not exactly helping your case that it isn't at all clear what that sample
is actually doing and what kind of practical task it might be used for.

I've been doing C# for years, use and enjoy Linq, and I can't remember the
last time I touched the comprehension syntax. IIRC, it does make a few
relatively obscure things easier than they would be with method and lambda
syntax, while there are a few different obscure things that are easier without
it. On balance, I lean against it as being yet another sub-language for you
and the rest of your team to learn and understand what it's really doing under
the hood.

~~~
random314
The sample is not clear?! How would you write the same asynchronous code in C#
without the LINQ syntax? Can you give an example? All the code does is get a
from async taska, b from async task b, feed the result of b into task c to get
c, and if c contains blah return c+a asynchronously.

~~~
ufmace
If you understand it, then exactly what are the return types of these tasks
and the types of a, b, and c? Are they single objects or IEnumerables?

If they are enumerable, then what exactly does c + a do? It is creating a new
enuerable of every a added to every c, like a SQL cross join?

If it is a single object, then what exactly does the where clause do? What
does it return if c does not contain blah, and what becomes of a in that case?
Does it get returned, added to null, disappear into the ether, or does it
figure out that it doesn't need it, and never actually evaluate taska? What
happens if taska modified some other state somewhere? For that matter, if it's
figuring that out, that would control the order that the tasks are evaluated
in. What is that, exactly? Is taska run at the same time as taskb, or does it
wait to see if there is actually a c to add to it's result? Or maybe it gets
evaluated before or after taskb, or at the same time.

That stuff matters. I'd rather make it clear at a glance what's going on than
write something super short and clever that nobody can figure out the details
of.

~~~
runT1ME
[http://mikehadlow.blogspot.co.uk/2011/01/monads-
in-c1-introd...](http://mikehadlow.blogspot.co.uk/2011/01/monads-
in-c1-introduction.html)

------
sandGorgon
even more interesting is that Spring Boot now supports Kotlin [1]. So you can
use
[https://start.spring.io/#!language=kotlin](https://start.spring.io/#!language=kotlin)
to generate a gradle project with Spring Boot.

[1] [https://spring.io/blog/2016/02/15/developing-spring-boot-
app...](https://spring.io/blog/2016/02/15/developing-spring-boot-applications-
with-kotlin)

------
thecupisblue
Been using it for a while, glad 1.0 is out! This is an amazing replacement for
Java on Android and hope it gets more public recognition now that it's
officially out.

~~~
zserge
I designed my reactive mvvm micro-library
([https://github.com/zserge/anvil](https://github.com/zserge/anvil)) for
Android with kotlin in mind, and so far it saved me lots time. Kotlin+Android
is a great choice.

~~~
zserge
And here are some examples of using Anvil with Kotling:
[https://github.com/zserge/anvil-kotlin-
demos](https://github.com/zserge/anvil-kotlin-demos)

------
merb
actually I'm still unsure about kotlin. some things are really great some
things are not. I mean i will still use kotlin, especially for libraries since
it is great for that. however somehow I still missed something on top of
Executors and CompletionStage. And I'm totally unhappy about "So, why doesn’t
Kotlin have its own package manager, or its own build system? Because there’s
already Maven and Gradle, and re-using their huge number of plugins is crucial
for many projects." The answer would be totally valid, however people who
worked with maven, gradle, ant or even sbt (which isn't offically supported)
could be unhappy. all of these build systems are useful, but not actually
great. I mean you could work with them but it's not actually great to use
them.

~~~
Nutomic
Can you name any criticism of Gradle? I've used it for years now (for Android
development). It's steadily being improved, and is really good in my opinion.

~~~
lmm
There's no clear separation between build config and random Groovy
expressions. There's not even a spec for what a .gradle file looks like.
That's fine for "get this done quickly", but ultimately it encourages people
to put one-off hacks in the build file that become a maintainability
nightmare.

(And because its "config" files are arbitrary turing-complete code, its IDE
integration is never going to be as good as Maven's)

~~~
pswenson
So I think gradle has a lot of problems, but having access to Groovy anywhere
is a good thing. You can always make your builds do what you want.

And as in all things if your code gets too complicated you need to refactor,
extract logic into methods/classes, etc.

~~~
lmm
You can always make your builds do what you want, but the flipside is you can
never understand what someone else is doing with their build. I don't think
the build system is the place for turing-complete code. Business logic
certainly doesn't belong there. Keep the build simple and standardized, and
keep code in code.

~~~
zmmmmm
I've arrived at the opposite opinion over time ... I think people need to
recognise that a build system _is code_. When we pretend it isn't we
ultimately end up contorting the system to make up for the missing
flexibility. A lot of it looks declarative, but it is not always the case.
Sometimes you want imperative constructs. The build should be recognized as
code, maintained as code and use a first class language suited to the job.

I do have a problem with Gradle which is that it is almost entirely magical
unless you are a pretty advanced Groovy programmer to understand how it is
doing what it is doing. I have never felt more disoriented than when trying to
learn how to customise a simple aspect of my build and having people post
snippets that work but seem completely disconnected from anything else in the
build process.

~~~
lmm
I think that when you _do_ need code in your build that code should be first-
class. Which means it should have test coverage, a release process, follow
your coding standards and all the rest of it. The maven plugin model
encourages that.

And maybe this is making a virtue of necessity, but I find the overhead of
creating a plugin stops people from putting random "different compiler
arguments on a Wednesday" conditionals in every build, which is all too common
if you give them immediate access to a turing-complete language.

------
claudiug
kotlin looks like swift for java. I hope google will remove java and start
adding kotlin as a first citizen :)

~~~
Alphasite_
The trouble between google and oracle wasn't about Java, it was about the Java
Standard Library and Harmony. Which wouldn't really be solved by Kotlin.

~~~
rabenblut
Irrelevant, Kotlin is still better than Java

------
kosiara
I’m already using Kotlin in my Android projects. So far it’s great! I’d also
done a presentation about Kotlin during our company’s Lightning talks. Take a
look here – Kotlin Developer Starter in Android projects.

[https://t.co/oVPJw1YIGa](https://t.co/oVPJw1YIGa)

------
vbezhenar
Congratulations to everyone involved. I like Kotlin and I hope to see it as my
main language for Java platform. I used it and it really "clicked" for me.
Almost everything was designed the right way in my opinion.

------
crudbug
I started looking at Kotlin docs [1]. For higher order functions support,

fun lock(lock: Lock, body: () -> T): T {

}

Is there any technical reasons why normal function declarations are not using
'->' as a return operator ?

fun hello(name: String) -> String {

    
    
         println(name)
    

}

Swift [2], Rust & others are using it.

It will just make the experience uniform with consistent __Functional Types __

[1][https://kotlinlang.org/docs/reference/lambdas.html](https://kotlinlang.org/docs/reference/lambdas.html)

[2] [http://fuckingswiftblocksyntax.com](http://fuckingswiftblocksyntax.com)

~~~
lmm
: T is consistent with values, it's the way of saying a thing has a type. It
makes for much more consistency when refactoring a function, and (at least in
Scala) supports the Uniform Access Principle style.

    
    
        def lock(...): T = ...
        val lockResult = lock(...): T
    

In Scala at least "=> T" is the syntax for a lazy T (i.e. a function of no
arguments that returns T), and so your "hello" reads like a function that
returns a lazy String.

------
crudbug
Congratulations on this release.

I see with Project Rider, JetBrains clear strategy to support major platforms
- JVM, Native, Web, CLR.

Is there a CLR backend planned for Kotlin ?

~~~
yole
The Kotlin team does not have any near-term plans to work on the CLR backend.
However, there are people at JetBrains who want one, so it's possible that it
will appear at some point in the future.

~~~
pjmlp
It would make a great portable language between Android and Windows Store,
removing the need to touch JNI in Android like we are currently forced to do
for any major OS APIS via C++.

------
hyperpallium
request: a dex of the compiler and any needed jars, so you can compile _on_ an
android device.

------
softinio
Must admit I wish Jetbrains just contributed more of their time on existing
open source languages instead of creating a complete new one. There is enough
languages out there and this is one more thing i wont have time to look at :)

Congrats though well done on release.

~~~
distances
Mostly Kotlin brings a real alternative to Android. The other languages either
don't run on JVM or are somehow else unsuitable, such as due to unacceptable
startup times.

It's almost like Kotlin was designed for Android to bring new life to its
ancient Java version.

------
wellpast
> Talking about [Kotlin] lines of code, the number of these in open
> repositories on GitHub is growing exponentially over time.

This could also mean you've designed a verbose and turgid language. A better
metric might be _# of projects_ using Kotlin. (For the record, I'm actually
really excited about using Kotlin, I just found it somewhat hilarious to boast
about exponential growth of LOC.)

