
Kotlin: A statically-typed language that compiles to JVM bytecode and JavaScript - shawndumas
http://kotlin.jetbrains.org/
======
laureny
Probably the most promising language on the JVM in my opinion, one that stands
a reasonable chance to see wider adoption than the faltering and overly
complex Scala.

Kotlin feels like an incremental improvement over Java that I can wrap my head
around and it comes with stellar IDE support right out of the box.

I hope they release a 1.0 soon so we can see if it gains traction, but it will
be challenging, because Java certainly seems invincible right now, and
probably for years to come thanks to the imminent Java 8.

~~~
camus2
Saying that scala is complex is like saying lisp is complex just because you
cant read it.

Scala has very little syntactic rules. Of course if you dont take the time to
learn them , you are not going to understand the language.

~~~
pron
No it isn't. Scala has three complete type systems: an OO, inheritance based
type system, a Haskell-like algebraic type system (sealed traits and case
classes), and a duck-typed type system (structural types). Each of these type
systems has been enough to write good, complex software on its own (in
different languages, of course). Scala's got all three, plus macros. Scala is
a superset of Java, Haskell, JavaScript and Lisp; such a language is not
simple. A language where it takes an expert to understand how the standard
library's linked list is implemented is not simple (even the language creators
say that understanding, let alone implementing, Scala collection classes is
reserved for experts). You may well understand parts of it, most of it or even
all of it given enough time, but it is definitely not simple.

EDIT: Scala does have an incredible compiler, though, and it is interesting
from a PL research POV (which is to be expected, given its origins). The JVM
community will forever be indebted to Scala. But it is not a language that
many will feel comfortable using, and most of those that do, use a subset of
it (which is basically Kotlin), and ignore the fact that they can't understand
how the linked list is implemented. Kotlin takes a lot of inspiration from
Scala, obviously, and learns from its mistakes. It takes that subset of Scala
that gives people 99.9% of what they want and need with only 10% of the
complexity.

~~~
kenbot
You ran with this "three complete type systems" line in the last thread, and
it's still totally wrong.

ADTs/pattern matching are not "a complete type system". Structural types are
not "a complete type system". Scala unifies the different concepts by
expressing them through Java-style classes and inheritance.

Even if they were incompatible non-orthogonal type systems sitting side by
side (they aren't), it is immensely useful to have both dynamic dispatch and
ADTs/pattern matching in the toolset; they are often useful for different
problems.

~~~
pron
> ADTs/pattern matching are not "a complete type system". Structural types are
> not "a complete type system"

Why not? Can you not write any program using either? Haskell uses just the
former, and JS the latter (though without type safety).

> Scala unifies the different concepts by expressing them through Java-style
> classes and inheritance.

I think it "unifies" them only in the sense that the (single) compiler can
compile all three. But case classes cannot be part of an inheritance hierarchy
nor structural types (or inheritance types) be used as ADTs. The three
certainly intersect, but they're not really _unified_.

> It is immensely useful to have both dynamic dispatch and ADTs/pattern
> matching in the toolset; they are often useful for different problems.

Obviously, and that is why some languages employ the one or the other. The
question is, how useful is it (from a cost/benefit perspective) to have all
three (plus macros!) in the same language? After all, while each has its
benefits sometimes, they also overlap a lot, as most programs are about as
easily implemented in all three. As I've said elsewhere, in language design,
as in most things, one must choose. A pizza, a steak and ice-cream all have
their place, but may lose much of their flavor if mixed into the same dish. In
the JVM ecosystem we are lucky enough to have easy interoperability between
languages. The JVM is a restaurant with a varied menu, and you can have a meal
of several courses. The best way to go, IMO, is to pick one simple language
you're comfortable with and use it for most tasks, and for those tasks that
require specialized skills outside your chosen language's strengths – use
another.

~~~
kenbot
> Can you not write any program using either?

While you can make do with either, they have complementary strengths and
weaknesses, which are useful in different situations. See "Expression
Problem", and "Visitor Pattern".

> Why not?

"Single Dispatch Polymorphism" is a language feature. ADTs/pattern matching
are a language feature. Subtyping is a type-system feature. "Structural
Typing" is a type-system feature. Guaranteeing exhaustive pattern matching is
a type-system feature. They are not "type systems", and different languages
pick them and combine them a la carte.

> But case classes cannot be part of an inheritance hierarchy nor structural
> types (or inheritance types) be used as ADTs

Yes they can, and they do. You just can't extend case classes from other case
classes. You can use any class as an ADT-like structure if you want, leaving
the hierarchy open or closed, and defining pattern matching extractors as you
please. It's all part of the same system; whether you call it an "ADT" or a
"class hierarchy" is a design pattern thing more than a rigid systemic
property.

> Obviously, and that is why some languages employ the one or the other

Er... that doesn't follow. What I said is that it's very useful having both
together. If you don't think that's valuable, that's fine; Scala's not for
you.

~~~
pron
Can you write any program with only case classes and sealed traits? Yes;
Haskell does it. Can you write any program with just structural types? Yes, JS
does it. Can you write any program with just inheritance types? Yes, Java, C++
and C# do it. Ergo, Scala has three type systems, and it doesn't matter
whether you make them appear as one.

> It's all part of the same system; whether you call it an "ADT" or a "class
> hierarchy" is a design pattern thing more than a rigid systemic property.

Obviously it's part of the same system, which just happens to be a superset of
three type systems. A type system is not how its implemented but what it does.

~~~
kenbot
You can write any program with a Turing machine. That's a silly definition of
a type system. I've never heard this usage anywhere else.

------
rnikander
> [...] the faltering and overly complex Scala

I use it everyday for work, and it's an excellent language. I think it
"falters" because it's more ambitious than anything else. Kotlin doesn't look
as ambitious so far. I'd rather stick with Scala and see them keep improving.
There are some promising ideas in the pipeline for future simplification
without loss of power: [http://www.infoq.com/presentations/data-types-
issues](http://www.infoq.com/presentations/data-types-issues)

~~~
lmm
If that's the one I think it is it, the proposal would make type-level
programming much harder to debug than it currently is (because it becomes
impossible to specify the types of type-level functions).

~~~
rnikander
I don't know what you mean here. I'd be curious to see an example.

~~~
lmm
Isn't it proposing to eliminate existential types that can't be expressed as
wildcard types? Or is this something different?

------
deathanatos
This has null-safety. As in, you can't assign null to a variable without
explicitly qualifying that variable as "nullable". Glad to see this.

But it's yet another language with strings-are-a-list-of-code-units. I've
mentioned it before, but I'd like more languages to follow Haskell/Python's
suite of "String are a list of code points", at the very least. (Those as
others have point out, while dealing with code points is less error prone than
code units, you probably want something even higher level.)

Integers are still range-limited. For some things this is okay, for some
things it'd be nice to not worry about what happens when you get near 4B.
Python solved this nicely. (There's a place for range-limited ints, and you
can always have a ranged_int<0, 65565> type, or something. But by default, I
don't want to think about overflow!)

Generics appear to be C#/Java like (i.e., limited, not full meta-programming).

Some things that run when targets to the JVM don't in JS. `for(c in "a
string")` didn't compile for JS, nor did `1000000000000000 or 0`. (To be sure,
this isn't exactly easy.)

(Last, the issue tracker infinite-redirects, likely because it doesn't handle
a browser rejecting cookies.)

~~~
DigitalJack
Could you take a crack at explaining code-unit vs code-point? I'd never heard
of them, and they sort of looked like the same thing on Wikipedia.

~~~
aardvark179
A code unit is the minimal bit length for a character in a particular
encoding, so in UTF16 that's 16 bits and in UTF8 it's 8 bits.

A code point is a character, that may be encoded by a single code unit or may
require multiple code units.

Mostly Java handles strings as 16bit code units, code point functions were
only introduced at 1.5.

~~~
DigitalJack
So, a dumb question, If a code unit is the minimal bit length for encoding a
character: why would you need more than one to encode a character?

Is this just a way of saying "variable bit length character encoding?"

~~~
lmm
If your character encoding is fixed-bit-length then a code point and a code
unit are the same thing yes. If your character encoding is variable-bit-length
then a code point is a "character" and a code unit is the thing that a
character may be 1 or more of (i.e. a byte in utf8, or a 2-byte thingummy in
utf16).

The point is that it's better to treat strings as sequences of unicode
codepoints ("characters") than treat them as sequences of 16-bit utf16 units
like Java does.

------
dgreensp
Does anyone know how Kotlin bridges the differences between the JVM and JS?

For example, the demo video that prints an ArrayList of Integers raises more
questions than it answers, given that JavaScript doesn't have Integers or
ArrayLists and has different built-in stringification (which is always
idiosyncratic from language to language). Can I write portable code that uses
arrays?

Some quick poking around indicates that Kotlin is pretty JVM-centric for
someone who works in the web world. (I used to write a lot of Java and Scala
and even wrote a mini JVM once, but these days JavaScript is my go-to
platform.) There's good old byte/short/int/long and there's boxing of
primitives. They don't even bother to mention that arrays have immutable size
(like Java and unlike JS), presumably because they assume it's obvious.

Inexplicably, the English words "and" and "or" are used for bitwise operations
while && and || are unchanged. Hate to criticize but it all just seems rather
strange.

~~~
hhariri
The demo (I'm the author of the video) is showing JVM, not JavaScript target.

For JavaScript, check out:

[http://blog.jetbrains.com/kotlin/2013/10/writing-kotlin-
in-t...](http://blog.jetbrains.com/kotlin/2013/10/writing-kotlin-in-the-
browser/)

~~~
camus2
First thanks for your excellent products. JetBrains rocks and i bought 2 ides
from your business.

Now my question :

Why didnt you chose an existing language like Dart for instance?which would
have been closer to java and still compile down to javascript. I think dart on
the jvm would be a great idea.

~~~
hhariri
Thank you.

Regarding Dart, AFAIK, we started working on Kotlin before Dart and Kotlin was
first focused exclusively to target the JVM. The JavaScript came afterwards.

------
niutech
It's old news - see
[https://news.ycombinator.com/item?id=2784086](https://news.ycombinator.com/item?id=2784086)

------
desireco42
I am honestly a little tired of one more language that is statically typed and
compiles in js. It really has to bring something huge for me to consider it,
even from name like JetBrains.

~~~
jonsterling
I am pretty tired of statically typed direct-to-JS languages which are wildly
unsound. I use TypeScript at work, and I grant it's hugely safer than
JavaScript and has saved us from dozens of defects even in the two weeks since
I introduced it, but its type system is pretty broken.

A DSL written in a dependently-typed language (such as Idris) would suffice
for both the kind of safety and the level of expressivity I require.
(Unfortunately, the various JS backends for Haskell, Idris, Agda, etc. are not
usable for my purpose, since I need the output to be readable and debuggable).

Anything less than what I have proposed in the previous paragraph is pretty
uninteresting to me. It's unfortunate that people are working so hard on
Kotlin, when it cannot contribute anything new or interesting, by its very
nature.

~~~
profquail
Have you looked at Haxe ([http://haxe.org/](http://haxe.org/))? It's supposed
to have a decent type system, although I can't say how it compares to
TypeScript's since I've used neither of them.

If you need a stronger type system, and you're already using TypeScript, take
a look at FunScript ([http://funscript.info/);](http://funscript.info/\);) it
uses the meta-programming features of F# to do strongly-typed JS (and
TypeScript) code generation and interop with existing code.

~~~
jonsterling
Thanks for the links! FunScript looks really neat.

------
woutervdb
Another day, another new programming language that compiles to [popular
language]. I'm sorry, I may be looking at this from the wrong perspective, but
in my opinion, they're starting to lose their value. Sure, accessing a hard
language (like C, or Python (for me, I find Python difficult at times) by
writing your own dialect or higher-level language can be fun and _maybe_ can
make your workflow better, for me it doesn't.

Actually, I view these higher-level languages as the program that ships with a
Raspbery Pi (don't know what it's called, sorry), which uses a drag and drop
interface to create loops and create a game. You'll learn the basics of
programming, but having a company where everyone speaks their own higher-level
language won't really work. You're especially f __ked if you 've got a
developer that has to read the generated code, in a _lot_ of cases.

Please correct me if I'm wrong, I'm still genuinely interested in the purpose
of such languages!

~~~
hhariri
Not exactly sure what you're saying here.

~~~
woutervdb
English is not my native language and I'm kinda busy, so it's pretty hard for
me to explain myself, sorry.

I'm saying that languages like these (if I understand correctly), when
compiled, result in a program generated by said language, "written" in another
language, like Javascript, Java, Python or something.

Personally, I see no value in doing so. It creates a bit of an "overhead" (you
compile it twice), and you actually don't really see what happens in the layer
below the layer you're working in: the JS/Java/Python layer.

Say you've been working in the language FooBar, which creates, say,
Javascript. Now most examples of code generators I've seen don't really care
about the readability of the code they output. They have a readable, human-
created bootstrap.js loading the default handler, and a bunch of semi-
obfuscated .js floating around.

Usually, this doesn't matter. However, I see a lot of these languages appear
on HN lately. The problem I'm starting to see is that, when we've got 10,000
alternatives to FooBar, people all start using different FooBar-like
languages, and it becomes a mess. If you, for example, like to write in
BarFoo, then we have a problem. We both understand JS, but the generated code
is a mess. What do?

Then again I could be wrong. :P

~~~
hhariri
Kotlin compiles down to JVM Bytecode, which will could be considered another
language, is what's required to run on the JVM. That's the JVM Target.

Now, from the JavaScript target, yes, it compiles down to JavaScript, but it
does so in a way that it not only provides sourcemaps to be able to debug, but
also be consumed from JavaScript via Common JS modules for instance, thus
allowing you to interact from JavaScript with the code you've written in
Kotlin. Think for instance replication of some business logic on both client
and server which is quite common.

Finally, in regard to writing Kotlin versus JavaScript, well Kotlin has it's
advantages if you prefer static typing and want some of the benefits that
language provides. If you're comfortable with JavaScript, if you prefer
dynamic languages, then there's little reason to use Kotlin to compile to
JavaScript (except the previous scenario of sharing code).

------
curtis
I am happy to see that there's some example code on the home page.

------
colig
I started using Kotlin on the weekend and I have been pretty happy with it.
The only issues I have with it so far is that I would like to use a package
name with more than two identifiers (eg. com.android.scripting, instead of
just com.android), and there isn't a succinct way of declaring
multidimensional arrays. I resort to doing something like

    
    
            val arr: Array<Array<Tile>> = Array<Array<Tile>>(height, { x ->
                Array<Tile>(width, { y -> Tile(x, y, Terrain.GRASS) })
            })
    

Now I'm looking at writing my array in Java instead and making good use of
Kotlin's interoperability with Java. :)

~~~
udalov
Most of the time you can omit type arguments:

    
    
            val arr = Array(height) { x -> Array(width) { y -> Tile(x, y, Terrain.GRASS) } }

------
eonil
I like to know whether this language support these stuffs.

\- C++ level of const correctness or a simple way to make immutable data
structure. Or immutable view of full data structure.

\- Explicit symmetric coroutine with safe data sharing machinery. I mean
something like Erlang process or Goroutine.

\- Any meta-programming facility such as macro or template.

~~~
hhariri
1\. Yes 2\. No 3\. A bit. Not macros or templates but nonetheless you can do
some type of meta programming with reflection.

~~~
mwcampbell
Do you plan to add macros or some other kind of compile-time metaprogramming?
I think it's important to have that, since reflection is at odds with
obfuscation and also introduces runtime overhead compared to compile-time code
generation.

~~~
abreslav
Many ideas of this sort are flying around, but we postpone the decision to
some time after 1.0

------
bjeanes
Is this JetBrains' answer to Eclipse's Xtend
([http://www.eclipse.org/xtend/](http://www.eclipse.org/xtend/))?

