
Kotlin: Statically typed programming language targeting the JVM and JS - tilt
http://kotlinlang.org/?
======
delecti
Am I the only one that really doesn't mind semi-colons?

I find it to be a drawback when they aren't required, because it introduces
unnecessary ambiguity. If I have to wrap a long line, then there's extra
syntax I have to remember to make sure the language realizes that this is all
"really" a single line.

~~~
k__
Can you elaborate?

I write LiveScript and never had a problem with this.

I prefer lesser symbols on screen.

On the other hand, LS has syntactically significant whitespace which lets you
indent wrapped stuff so the compiler sees that it still belongs to the
previous command, in many cases.

~~~
delecti
Specifically in Python, if you're appending lines of text, for example, then
you have to add a \ before the newline. Also in Javascript if you omit the
semi-colon then sometimes the interpreter gets confused and functionality gets
jumbled.

Sorry if that's not that specific. I just in general prefer semi-colons being
required, because then it fails fast rather than producing subtle bugs later.

------
altschuler
A detail I've noticed when compiling to JavaScript is that Kotlin is not a
reserved word, and if you bind something to it, it breaks the generated
JavaScript.

fun main(args : Array<String>) {

    
    
      println("Hello, world!")
    
      val Kotlin = 0
    

}

will result in a type error

------
xiaoma
It was really interesting to see Prezi on the list. They hired the creator of
Elm and are one of the very few places if not the only place using it in
production. If they're using this too they must be a linguistically fearless
shop.

See this demo and try using the arrow keys to move the turtle: [http://elm-
lang.org/edit/examples/Intermediate/Turtle.elm](http://elm-
lang.org/edit/examples/Intermediate/Turtle.elm)

~~~
laszlok
[http://engineering.prezi.com/blog/2014/01/20/prezi-the-
land-...](http://engineering.prezi.com/blog/2014/01/20/prezi-the-land-of-the-
polyglots/)

------
fstephany
It seems that they don't advertise Android support on the website. Is it
dropped?

More info here: [http://blog.andresteingress.com/2013/12/13/programming-
andro...](http://blog.andresteingress.com/2013/12/13/programming-android-with-
kotlin/)

And there: [http://blog.jetbrains.com/kotlin/2013/08/working-with-
kotlin...](http://blog.jetbrains.com/kotlin/2013/08/working-with-kotlin-in-
android-studio/)

~~~
hhariri
Absolutely not! :) In fact under the Features, if you scroll to Versatile
card, it's there. We're also working on Android tutorials.

~~~
fstephany
This is great to hear. Thanks!

------
pjmlp
With Google's move to InteliJ for Android development, I kind of hoped that
they might sponsor Kotlin, but alas Google IO 2014 comes by, and they reaffirm
at the Android Team Fireside that only Java and C++ have an welcoming place in
Android development. With no official plans for Java 7+ support.

~~~
Benjamin_Dobell
Well, Google have officially dropped Dalvik (i.e. a JVM) in favour of ART
(pre-compilation to native code). This is the perfect opportunity to open up
the platform to a plethora of new programming languages without needing to
worry about being JVM compatible. Instead an LLVM back-end can be produced to
compile straight down to ART ABI compatible native code.

~~~
mike_hearn
ART is a JVM, it's just not a just-in-time compiling JVM.

The JVM is fine for multiple programming languages, as Kotlin nicely proves.
And Kotlin targets Java 6 so it should work fine on Android, even though now
Android supports Java 7 language features. The missing parts are the Java 7
API's: unfortunately the class library, being based on Apache Harmony (a dead
project) does not move forward on Android. However this does not have any
effect on Kotlin.

------
iaskwhy
I didn't know much about Kotlin but I found out the landing page to be very
informative in a pratical way. Nice work, designer(s)!

------
munro
Looks similar to Haxe, in that they're targeting interoperability. But with
less platform support.

I personally have yet to use Haxe, but the people I know who use it love it.
I'm keeping it in mind for a good use case! Such as sharing application logic
across applications, though in practice last time I did that things got very
messy, it was easier just to duplicate application logic across applications.
Kotlin/Haxe would be great for cross platform libraries though.

Both Kotlin and Haxe do have GADT, which is a feature I'm finding harder to
live without :D Also Kotlin appears to have record types!

~~~
adrusi
Kotlin seems to be a good deal simpler than Haxe. Haxe seems to be closer to
Scala in terms of complexity, while Kotlin really just boils down to a few
extra features relative to Java 8.

As far as I know, Kotlin does not have algebreic data types. It does have the
nullable type `T?` which is basically Option or Maybe, but you can't define
your own.

Haxe's enums are algebreic types, but I don't think it has full support for
generalized algebreic data types.

~~~
jdonaldson
Haxe has GADTs, and I think they're great.
[http://en.wikipedia.org/wiki/Haxe#Type_system](http://en.wikipedia.org/wiki/Haxe#Type_system)

------
minaandrawos
It seems interesting but I find myself comparing it to Eclipse's Xtend
([http://www.eclipse.org/xtend/](http://www.eclipse.org/xtend/) ). Does anyone
know if it has an advantage over Xtend?

~~~
galaxyLogic
Cool thing about Xtend is that you can actually understand the Java it
generates. So once you've used Xtend to generate the Java you can forget about
Xtend if you want to. You are not "married" to it.

You can later take a Xtend-generated Java-method and start manually modifying
it if needed.

I just wish Xtend had more support from others besides Eclipse. Also I hope it
gets its Ant -support to a better shape, maybe it already is. It is simply a
smarter simpler way to write Java. And you don't need to go Java 8 to benefit
from "Lambdas".

~~~
galaxyLogic
Also Xtend chose its name poorly. It's hard too google it without getting
advice on how to extend your life etc.

SEE: [http://www.eclipse.org/xtend/](http://www.eclipse.org/xtend/)

------
bellerocky
How good are Kotlin's async options? It's not like Java threads I hope. I like
Kotlin, but a good asynchronous mechanism or real coroutines are really
important.

~~~
mike_hearn
With lambdas, futures are quite easy to use and compose.

~~~
MichaelGG
Until you start nesting them and doing exception handling...right?

~~~
spullara
No, checkout CompletableFuture in Java 8. Nesting and exception handling is
pretty great I think.

~~~
MichaelGG
I looked a quick tutorial - it seems to be just a normal continuation-based
approach. If want to have a single try/catch block for a bunch of code that
calls many different async tasks among other things, how does that work?

~~~
spullara
It all flows through flatMap and other methods on CompletableFuture and you
can catch the failures only once at the top level future that collects it all.
That is the value of promises over callbacks generally. This might be a little
convoluted to see what I am talking about:

[https://github.com/spullara/java-future-
jdk8/blob/master/src...](https://github.com/spullara/java-future-
jdk8/blob/master/src/test/java/spullara/util/concurrent/CompletableFutureTest.java)

The basic idea is that if you have a bunch of Futures you can flatMap them all
together and have only a single exception handling block if that is what you
want. Or you can handle the exceptions at any level and convert them. Makes it
very nice to handle partial failures and the like.

~~~
MichaelGG
The sample looks like any other closure-based framework, to me. Compare to C#,
for instance, I can just do this:

    
    
      try { 
        var a = await Function1Async()
        var b = await Function2Async(a);
        try {
          var c = nonAsync(a,b);
          await AnotherThingAsync(c);
        } catch { ... }
      } catch { 
        ...
      }
      finally {
        ...
      } 
    

This generates the callback mess (every await is an async call), figures out
the right parts of the exception/finally handlers to run, etc. etc. I don't
see how this can be remotely approached if the only syntax you have is
lambdas. You need some sort of rewriting system, either by a special keyword
(C#), or monad-like thing (F# workflows) or something.

~~~
spullara
Not at all. Here is the equivalent pseudo code:

Function1Async() .flatMap(a -> a, Function2Async(a)) .map( (a, b) ->
nonAsync(a, b)) .flatMap(c -> AnotherThingAsync(c)) .error(e -> catch)
.complete( finally );

The real code would be a little more complicated but not much.

------
skybrian
They say up front that it compiles to JavaScript but there should be more
documentation about that. Where are the HTML5 API's? How does JavaScript
interoperability work?

~~~
hhariri
What things would you like documented? We're working on providing more
tutorials, docs and information. The API docs are being revamped. Old ones
have info about DOM/HTML/Browser support:

[http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/...](http://jetbrains.github.io/kotlin/versions/snapshot/apidocs/index.html)

~~~
skybrian
If I want to write a web application and I go to the API reference, it's
unclear where to start. It should say whether each library is browser-only,
server-only, or works in both places. For example, is kotlin.dom a client or
server API? How about kotlin.io? It says that kotlin.io writes to System.out
which is a server-side concept, so I'd guess it's server-only?

It would also be nice to see examples of how to embed kotlin-based JavaScript
in a web page, how to call JavaScript from kotlin, and how to expose a
callback function to JavaScript.

A good way to help web developers get started might be to port the examples
from the React front page to Kotlin.

~~~
hhariri
Thanks. The API docs are being revamped as I mentioned and those things we
hope to solve. We're also working on tutorials for JS. Right now you can see
info on JS here:

[http://hadihariri.com/2013/10/16/writing-kotlin-in-the-
brows...](http://hadihariri.com/2013/10/16/writing-kotlin-in-the-browser/)

which discusses usage, interop and getting started.

------
dothething
Why Kotlin over Groovy? Because it's statically typed? Is this an evolutionary
thing, or just preference?

~~~
vorg
Kotlin's for building large software systems using the tightly-integrated
IntelliJ plugin, both from Jetbrains. It was built with that use case firmly
in mind, and even had contributions from James Strachan (Groovy's creator) and
Alex Tkachman (creator of Groovy 2.0's, ummm..., inspiration Groovy++).

Groovy's for gluing together Java and JVM apps, testing Java objects,
scripting for Grails, 20-line Gradle build scripts, and what not, anything
that doesn't scale.

~~~
virtualwhys
What large software systems have been written in Kotlin? I was under the
impression that until at least v1.0 (sometime next year?) there is no
guarantee of API stability (i.e. there have been and will be breaking
changes).

Perhaps Kotlin _will_ be for building large software systems is a bit more
accurate.

As for Groovy, Grails performs surprisingly well[1] with Groovy as the primary
language (i.e. that the developer uses to create controllers, models, etc.).
Would have expected it to fall on its face with a dynamic language in use, but
no, hangs in there right around the middle of the pack.

[1]
[http://www.techempower.com/benchmarks/#section=data-r9&hw=pe...](http://www.techempower.com/benchmarks/#section=data-r9&hw=peak&test=db)

~~~
vorg
> Perhaps Kotlin _will_ be for building large software systems

Are you arguing over what tense I used? When Jetbrains first announced it was
building Kotlin, they wrote it would be designed to be used with IntelliJ, and
that they'd then use it for their own internal software product builds. So it
_is_ for building large systems, that's its purpose.

When Groovy's creator announced Groovy, it was to be used to script Java. When
Graeme Rocher took it over, he put in a MOP so it could be used with Grails,
and later a DSL syntax for Gradle and a static compilation mode because it was
there.

------
thescrewdriver
From the site: Version: 0.8.11

------
martingordon
This looks a lot like Swift (or rather, Swift looks a lot like Kotlin).

~~~
mike_hearn
A lot of modern languages look like this now. You could as well say they both
look like Scala. But then, Scala also riffs off languages like Haskell in some
vague syntaxy way.

Swift, I think, is strongly influenced by design trends in modern programming
languages. I didn't see a whole that in it that was new though.

~~~
owlish
From what I see in the clip on the front page, some of the syntax is certainly
reminiscent of Groovy as well

~~~
pjmlp
ML actually

~~~
mavelikara
I think GP meant (1) the use of "it" as the implicit name of a single argument
closure and (2) string interpolation syntax.

------
discreteevent
Does anyone know how mature js generation and interop is?

------
timclark
Is someone bypassing the duplicate submission logic by editing URLs.

Earlier submission here -
[https://news.ycombinator.com/item?id=8036515](https://news.ycombinator.com/item?id=8036515)

~~~
tilt
Can't actually reach the previous one, still this one is more related to
[http://blog.jetbrains.com/kotlin/2014/07/a-new-open-
source-w...](http://blog.jetbrains.com/kotlin/2014/07/a-new-open-source-web-
site/)

~~~
timclark
It works for me, It looks like you've just pasted a ? on the URL.

~~~
Kiro
A bannable offense in my opinion.

~~~
bjz_
I'm cool with somebody re-posting for a site update. I wouldn't have known
they'd updated otherwise.

~~~
Kiro
But allowing it encourages people to game the system by reposting things that
have been upvoted before.

~~~
coldtea
If those things are interesting enough to people (including those reading them
for the first time on the nth posting), to be upvoted multiple times, then
it's not "gaming the system".

What we should care about is if we have interesting articles to read -- and if
people that might have missed something in the past have a chance to see it,
that's for the better.

There have beens lots of very lively discussions on the 3rd and 4th posting of
the same story, and I wouldn't want those people to miss the post entirely, or
those conversations to never happen.

As for the duplicate poster getting points from something he knows will be
popular again, well, nobody cares if he does get the points. HN is not some
silly high score competition.

------
JustSomeNobody
Designing a new language is the new designing a new framework. Ugh.

~~~
laureny
Yeah, screw progress and experimentation, right?

~~~
JustSomeNobody
If all the languages and frameworks that are being developed were progress,
then sure. If they were meant as just experiments, then more power to them.
Here's the deal, we'll see a flood of "Why I chose (X) language" posts. A year
later we'll see a flood of "Why I left (X) language" posts. Developers read
too many blogs and follow too many fads. They are like golfers! "This'll get
you an extra 10 yards on your swing!" B.S.

~~~
laureny
You're making the dangerous assumption that a failed experiment is synonymous
with no progress.

We actually learn a lot more from failures than successes.

~~~
JustSomeNobody
I am not assuming that at all. Re-read my first two sentences.

The problem that I see is that developers only want to work on what is new.
They don't want to work with C++ because it's old. They don't want to work
with Java because it's old. They don't want to work with Ruby because even it
is old. It's the same thing with frameworks. There has been an explosion of
frameworks because developers can't be caught dead working on something older
than 6 months.

If one's intention is to rewrite entire applications every year, knock
yourself out. But if you're writing apps for customers who expect it to be
solid and remain in the field for a useful amount of time, then you need the
reliability of C++ or Java or C. Not some language someone whipped together in
a handful of weekends.

Another commenter mentioned beginning development because it was fun. I did
too. It still is, but I also grew to care about the products I develop. And
no, it's not fun to chase issues with immature technology when a customer is
wanting answers.

