

Project Kotlin - a statically-typed JVM language developed by JetBrains - rpeden
http://confluence.jetbrains.net/display/Kotlin/Welcome

======
Dn_Ab
This language looks excellent, looks just right in goldilocks terminology.
Also I like a lot of their justifications, especially their answer to
functional programming. While I mostly agree with what they say, even where
you don't agree, what they say still makes sense. They know they are talking
about and know exactly what they seek to address so this seems different from
a yet another X.

I have 2 questions though. They have reified generics. Something even Scala
lacks. Does the ability to retain this information at runtime on a platform
without inherent support for this cause noticeable slow down or is it
practically negligible especially when compared to typical bottlenecks?

And although they mention it compiles to java byte code I would be curious to
know if it lugs a runtime. This will be key for easy android support.

I like that it has function inlining, this is something from F# that when used
carefully leads to generous payoffs that is missing in Scala. Their module
system is another thing which sets them apart, although I don't know if their
approach will yield much. In my limited experience nothing in wider use has
yet approached Ocaml's module system for power and usefulness.

This language looks quite good, I will be very interested to see how it goes.
It not only improves Java it actually leaps frog over C# as well.

\------------------------------------------------------------------------------------------

 _Why I think this language is a more likely candidate for Java.next_

-It is an OOP language. It is not functional, not a hybrid. They make this clear and that fact will appeal to the people it targets.

-Reified Generics.

-no checked exceptions

-It uses farmiliar curly brace syntax. And does so consistently. While I prefer whitespace I suspect this is a minority view.

-Pattern Matching. Pattern matching, especially their implementation is not so hard and once you get used to that idiom you won't want to go back to mere switch.

-It is built by a Tooling Powerhouse.

-Higher (first) order functions just sound fancy. They are actually simple and useful. Especially to library writers and allow a more composable and durable(imo) type of extension.

-It has a well thought out type system. The fact that they are thinking about introducing reified higher kinds on the JVM and their approach to the variously prefixed variances is enough said.

-It is statically typed. This is a religious issue to many. But fact is that _right now_ these type of languages are easier to tool, the idioms are more known to the type of people who use Java, and the performance is an issue for some. And for a minority the mathematics of a properly implemented statically typed system allows you to optimize code in an algebraic way.

-It is a definite improvement over Java but not in a way that uses scary vocabulary. In Kuhn's work both the paradigm shift and gradual changes are vital.

-It originates as a language that targets industry. When Scala first started it was an academic language built to prove the applicability of certain theories. There is nothing wrong with this and Scala is certainly production capable now but it retains its heritage. It is a very big language conceptually, pushing at the forefront of many ideas. Sure you can only use the small part of Scala but if you read behavioural pyschology stuff you know framing is a big deal. Saying that you are using a small part of the language even though thats all you need will cause a lot more uptake friction than saying you are using all of the language. Irrational but valid. The fact that Kotlin is being built to address a flaw in the market from the get go sets the culture out on the right foot.

 _Why use Scala instead of this_

From a brief look this language seems smaller and easier to use than Scala
-while also retaining most of the parts that make Scala better than Java. So
the question IMO is why use Scala instead of this.

They mince no words in emphasizing that this is an OOP language. So if you
prefer functional programming, Scala will be more idiomatic with certain
syntatical affordances. In built ability to map and fold for example. Scala's
type system is also more powerful and the syntax more flexible (with its own
caveats) and most importantly the collections will be more functional and
featureful. Like clojure, support for more future facing techniques and
concurrent, parallel programming will probably be stronger in Scala.

 _What would be nice in my opinion_

-Early support with nice tooling for Android. The documentation and tooling for Android leaves a lot of room for ehm.. improvement.

-Syntatical sugar for asynchronous programming.

-I cant't really think of anything else.

~~~
smcj
Just a few thoughts...

\- Scala has function inlining, look at @inline.

\- Module system: this looks extremely wonky, especially considering what
Oracle is planning with Jigsaw

\- Pattern matching is extremely hard to get right

\- "No hybrid", "industrial", that seems to be a pure marketing move,
considering that even 95% of the syntax is the same as in Scala, together with
types like Unit, Any, ...

\- Kotlin is pretty much in the same complexity level currently, without being
nearly as clean and orthogonal as Scala.

My estimate is that as soon as someone writes more than a few hundreds of
lines of code in Kotlin, things will break down, especially in the collections
area, features get thrown in, complexity explodes.

If they want to have some primitive Java-like collection design, then maybe
not. But judging from their comments they want to have a design with higher-
order functions (like map, filter, flatten, flatMap, partition, ...), they
_will_ need higher-kinded types. The problem is that higher-kinded types don't
work well with reified generics.

I know it is quite popular to bicker about the "complexity of Scala", mostly
coming from people having visited the webpage for a few minutes and not from
those people using Scala in industry daily.

> They mince no words in emphasizing that this is an OOP language.

Scala is as OO as Kotlin, no compromises here.

> "Scala's syntax more flexible (with its own caveats)"

Not really. Scala and Kotlin share almost the same syntax (apart from <> vs.
[] for generics).

I really wonder ... Microsoft is constantly increasing the margin between
their languages (C#/F#) and Java, while the Java community as a whole has
nothing better to do than being a huge bickering load of "language experts"
getting nothing done at all.

The question is: Should we really wait for yet another language like Gosu,
Fantom, Ceylon, Kotlin, ... to be usable in 2020?

Or should we maybe just starting to use Scala, which is proven, mature and
stable, has received tons of bugfixes over the last then years, has a complete
language specification, runs on JVM, with work being done to let it run on the
CLR and on the LLVM, with a JavaScript compiler in the works, with a huge
useful and clean standard library, with tools to check if JAR files are binary
compatible, with a great amount of third party libraries, ...

~~~
Dn_Ab
I think you read my post wrong. I too am skeptic of the module system. I
highlighted why I think this language will be more likely to be used as a
better Java by thinking like the hypothetical target. I also noted a key fact
that framing is a big deal. So while your conclusion makes perfect sense, it
fails to give psychology enough weight. Scala can do OOP well yes but it also
caters to functional programming. Kotlin seems like it will not go out of its
way to do so. To some people this is good. I prefer functional programming and
so would still use Scala by default when on the JVM.

Pattern matching is easy to get good enough. In fact I've never found a
pattern matching system that I wasn't happy with. Scala's case classes are
powerful but a bit different to the norm, I think Kotlin's will be more
familiar to many by de-emphasizing algebraic types. But they do clutter it
with what in Scala would be called extractors.

As for syntax. People create crazy DSLs by leveraging corner cases in scala's
lenient syntax, Kotlin seems to restrict there. I think this is a good thing
for many people. I came to Scala with a good amount of functional programming
experience, I found its concepts dead easy. The hardest part was the syntax
and how many different ways there were to do some simple things e.g. function
syntax and proper uses of _ are tricky for the new comer.

How is Scala big? For the reasons I think it is wonderful and would rather use
it. Existential types, extractors, implicits, optional laziness, currying,
actors, composing with maps and fold at the forefront. I think it is elegant
but most people prefer to just get the work done. By the way, you don't need
higher kinded types to do a collections library which takes first order
functions. You just need higher kinds for succinctness.

I will note that I mostly write F# code and am less familiar with the JVM -
thanks for the correction on inline. Although Scala's doesn't seem to be of
the same caliber as F#'s based on a cursory search. Do correct me on this too.
Although Scala does have a higher kinded type system. Unlike F#. In F# I
sometimes have to abuse inline to get around this limitation.

------
mullr
Notable features that are different from your many java.next candidates:

\- Non-nullable types by default!
<http://confluence.jetbrains.net/display/Kotlin/Null-safety>

\- No checked exceptions:
<http://confluence.jetbrains.net/display/Kotlin/Exceptions>

\- Native delegation support:
[http://confluence.jetbrains.net/display/Kotlin/Classes+and+I...](http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-
Delegation)

This looks like a language I could enjoy programming in, overall. The explicit
goal of being simpler than scala sits well with me.

~~~
bad_user
You forgot reified generics and no type erasure.

I wonder how this works, if it is compatible with generic classes defined in
Java and if they optimize the implementation for primitives.

~~~
SystemOut
If I had to guess they are probably sub-classing the built in collection
classes under the covers to add in metadata slots for things like type
information. As long as they implement the appropriate collections interface
or class I don't see why they wouldn't be compatible with generics classes
since none of type details ever makes it into the runtime.

------
dmcg
"The open annotation on a class is the opposite of Java's final: it allows
others to inherit from this class. By default, all classes in Kotlin are
final, which corresponds to Item 17 of Effective Java: Design and document for
inheritance or else prohibit it."

This is an odd decision, puts me in mind of Yegge's rant -[http://steve-
yegge.blogspot.com/2010/07/wikileaks-to-leak-50...](http://steve-
yegge.blogspot.com/2010/07/wikileaks-to-leak-5000-open-source-java.html)

~~~
masklinn
Does C# not use the same default of non-inheritable classes? Or is it just at
the method level, where you have to mark methods as overridable?

~~~
ppog
Classes in C# are inheritable by default, as in Java, but can be marked sealed
(final). Members (methods and properties) in C# are final by default, and must
be explicitly marked virtual.

~~~
frou_dh
For what it's worth, Jon Skeet of StackOverflow fame and C# fanaticism, thinks
C# classes should also be sealed by default.

 _"I'd say it was just a mistake. I know many people (including myself) who
believe that classes should indeed be sealed by default. There are at least a
couple of people in the C# design team in that camp. The pendulum has swung
somewhat away from inheritance since C# was first designed. (It has its place,
of course, but I find myself using it relatively rarely.)"_

------
buff-a
For class based languages I am completely beholden to good tools for
refactoring and the like, so rarely does a new language work for me in the
long term no matter how much fun it is. But these guys make the best tools in
the world. And as much as I like the usability of the JVM and the plethora of
awesome libraries, I find Java frustrating compared to C#. This Kotlin could
be just what I'm looking for.

------
canadiansaur
I have to say that i really like the looks of this language (at least as much
as i can without having programmed anything in it) - it seems to fix all the
major problems with java, without completely changing the paradigm.

And while I love scala, i like this language even more, since scala's
implicits are a bit too 'magical' for my taste, and I think it scala
overvalues terseness at a cost of readability

------
spooneybarger
I don't use scala, I've played around with it a bit. The question I have when
reading though this is, why would I use Kotlin instead of Scala? Can anyone
after reading about Kotlin lay out where the really large differentiators are
that would seriously sway someone one way or another?

~~~
mike_esspe
Here is a comparison:
[http://confluence.jetbrains.net/display/Kotlin/Comparison+to...](http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala)

Personally, i don't see a convincing reason to switch. Though absence of type
erasure is nice

~~~
spooneybarger
I'm not really swayed by comparisons that include things like: 'Complicated
logic for initialization of traits'.

Does Kotlin have traits or something similar? If yes, are they complicated to
initialize? If not, then does it matter as a point of comparison that Scala
has something that might be complicated if Kotlin offers nothing comparable?

I'm really mostly working from a high level of ignorance here.

~~~
bad_user
Dude, read the fucking docs before passing judgment.

[http://confluence.jetbrains.net/display/Kotlin/Classes+and+I...](http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance)

Basically the language has no notion of interfaces; preferring instead
multiple inheritance. Then the diamond problem is taken care of by making
mandatory the overriding of conflicts. See the provided example:

[http://confluence.jetbrains.net/display/Kotlin/Classes+and+I...](http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-
Diamondinheritance)

Then, it also has syntactic sugar for the Delegation pattern:

[http://confluence.jetbrains.net/display/Kotlin/Classes+and+I...](http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-
Delegation)

One cool thing about Scala's implicit conversions is that they eliminate many
use-cases which would make you use traits. Kotlin has a similar mechanism, but
kind of different (taken from C#); extension methods:

[http://confluence.jetbrains.net/display/Kotlin/Extension+fun...](http://confluence.jetbrains.net/display/Kotlin/Extension+functions)

The classic trait I'm thinking about when thinking about traits is the
Enumerable module in Ruby:

<http://www.ruby-doc.org/core/classes/Enumerable.html>

This is a classic example of where a trait is useful for providing common
implementation for collections that only have to implement "each". The cool
thing about extension methods is that you can implement all those methods in
the Enumerable module above, without dealing with multiple inheritance or
traits.

The difference between implicit conversions and extension methods is that
implicit conversions are more flexible, but extension methods are easier to
reason about and (being statically resolved at compile-time) don't suffer from
performance penalties.

I'm not saying that what Kotlin does is better than Scala, but it does seem
simpler. Personally I can't wait to play with it.

------
gtani
TODO:

code a little Fantom, Gosu, Nemerle,

and some Ceylon when it's out

and some kotlin (ditto

~~~
riffraff
I can't stop trying to see this as an haiku.

~~~
gtani
I've spent a lot of time building SOLR/lucene indexes, so I'm good at
stemming, but not too good at counting syllables.

------
Jach
This has a very pleasant language smell. It's sort of what I thought Go should
have looked like but didn't.

It'd probably be easier to convince a workplace to use this over Clojure
too...

------
steele
yeah, but where's the tooling? ;)

~~~
bokchoi
You do realize that JetBrains' IDEA is one of the best IDEs available? I'm
pretty sure Kotlin will get first class support in their editor.

~~~
spooneybarger
I think the ;) was an indication of that being a joke.

~~~
bokchoi
I must be up past my bed time again.

------
dmcg
On the one hand this looks like an admirable attempt to collapse the
essentials out of Scala while removing the cruft.

On the other, most of Scala's features got there for a reason, and have had
years to be honed into a cooperating set. It will be fascinating to see what
needs to be added to Kotlin in the next year.

------
bad_user
Unfortunately I can't find a way to download and play with it.

~~~
cmontgomeryb
The first public release is pencilled for the end of 2011.

------
steilpass
I like the Native delegation support. The only other language I've seen that
favours delegation is Objective-C / Cocoa. What are other examples?

~~~
YEPHENAS
Go

