7 ms·

Project Kotlin - a statically-typed JVM language developed by JetBrains

113 points by rpeden 15y ago

canadiansaur 15y ago
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
mullr 15y ago
Notable features that are different from your many java.next candidates: - Non-nullable types by default! http://confluence.jetbrains.net/display/Kotlin/Null-safety http://confluence.jetbrains.net/display/Kotlin/Null-safety - No checked exceptions: http://confluence.jetbrains.net/display/Kotlin/Exceptions http://confluence.jetbrains.net/display/Kotlin/Exceptions - Native delegation support: http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-Delegation http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... 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 15y ago
  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 15y ago
    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.
- cageface 15y ago
  As much as I admire Scala, I do think it's just too complex to contend seriously as a Java replacement. Something like this could be exactly what's needed to keep the JVM platform alive (assuming Oracle's legal stunts don't kill it). This might be the final push to get me to try my hand at an app if I can use this for Android.
steele 15y ago
yeah, but where's the tooling? ;)
- bokchoi 15y ago
  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 15y ago
    I think the ;) was an indication of that being a joke.
    - bokchoi 15y ago
      I must be up past my bed time again.
spooneybarger 15y ago
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 15y ago
  Here is a comparison: http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala http://confluence.jetbrains.net/display/Kotlin/Comparison+to... Personally, i don't see a convincing reason to switch. Though absence of type erasure is nice
  - spooneybarger 15y ago
    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 15y ago
      Dude, read the fucking docs before passing judgment. http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... 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+Inheritance#ClassesandInheritance-Diamondinheritance http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... Then, it also has syntactic sugar for the Delegation pattern: http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-Delegation http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... 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+functions http://confluence.jetbrains.net/display/Kotlin/Extension+fun... 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 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 15y ago
TODO: code a little Fantom, Gosu, Nemerle, and some Ceylon when it's out and some kotlin (ditto
- riffraff 15y ago
  I can't stop trying to see this as an haiku.
  - gtani 15y ago
    I've spent a lot of time building SOLR/lucene indexes, so I'm good at stemming, but not too good at counting syllables.
bad_user 15y ago
Unfortunately I can't find a way to download and play with it.
- cmontgomeryb 15y ago
  The first public release is pencilled for the end of 2011.
buff-a 15y ago
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.
dmcg 15y ago
"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-5000-open-source-java.html http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-50...
- masklinn 15y ago
  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?
  - dmcg 15y ago
    You have to mark methods as virtual - I believe classes are by default.
  - ppog 15y ago
    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 15y ago
      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.)"
    - masklinn 15y ago
      Ah, that's where I got confused, I remembered there was something in C# which made classes not-really-inheritable by default but had no way to test it.
dmcg 15y ago
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.
steilpass 15y ago
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 15y ago
  Go
Jach 15y ago
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...
Dn_Ab 15y ago
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.

113 points by rpeden 15y ago

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

mullr 15y ago

Notable features that are different from your many java.next candidates: - Non-nullable types by default! http://confluence.jetbrains.net/display/Kotlin/Null-safety http://confluence.jetbrains.net/display/Kotlin/Null-safety - No checked exceptions: http://confluence.jetbrains.net/display/Kotlin/Exceptions http://confluence.jetbrains.net/display/Kotlin/Exceptions - Native delegation support: http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-Delegation http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... 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 15y ago
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 15y ago
  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.
cageface 15y ago
As much as I admire Scala, I do think it's just too complex to contend seriously as a Java replacement. Something like this could be exactly what's needed to keep the JVM platform alive (assuming Oracle's legal stunts don't kill it). This might be the final push to get me to try my hand at an app if I can use this for Android.

steele 15y ago

yeah, but where's the tooling? ;)

bokchoi 15y ago
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 15y ago
  I think the ;) was an indication of that being a joke.
  - bokchoi 15y ago
    I must be up past my bed time again.

spooneybarger 15y ago

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 15y ago
Here is a comparison: http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala http://confluence.jetbrains.net/display/Kotlin/Comparison+to... Personally, i don't see a convincing reason to switch. Though absence of type erasure is nice
- spooneybarger 15y ago
  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 15y ago
    Dude, read the fucking docs before passing judgment. http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... 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+Inheritance#ClassesandInheritance-Diamondinheritance http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... Then, it also has syntactic sugar for the Delegation pattern: http://confluence.jetbrains.net/display/Kotlin/Classes+and+Inheritance#ClassesandInheritance-Delegation http://confluence.jetbrains.net/display/Kotlin/Classes+and+I... 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+functions http://confluence.jetbrains.net/display/Kotlin/Extension+fun... 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 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 15y ago

TODO: code a little Fantom, Gosu, Nemerle, and some Ceylon when it's out and some kotlin (ditto

riffraff 15y ago
I can't stop trying to see this as an haiku.
- gtani 15y ago
  I've spent a lot of time building SOLR/lucene indexes, so I'm good at stemming, but not too good at counting syllables.

bad_user 15y ago

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

cmontgomeryb 15y ago
The first public release is pencilled for the end of 2011.

buff-a 15y ago

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.

dmcg 15y ago

"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-5000-open-source-java.html http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-50...

masklinn 15y ago
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?
- dmcg 15y ago
  You have to mark methods as virtual - I believe classes are by default.
- ppog 15y ago
  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 15y ago
    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.)"
  - masklinn 15y ago
    Ah, that's where I got confused, I remembered there was something in C# which made classes not-really-inheritable by default but had no way to test it.

dmcg 15y ago

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.

steilpass 15y ago

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 15y ago
Go

Jach 15y ago

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

Dn_Ab 15y ago

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.