Project Kotlin - a statically-typed JVM language developed by JetBrains(confluence.jetbrains.net)
confluence.jetbrains.net
Project Kotlin - a statically-typed JVM language developed by JetBrains
http://confluence.jetbrains.net/display/Kotlin/Welcome
12 comments
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, ...
- 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, ...
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.
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.
> 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?
You need to generate a type for it at compile time, but I expect there's not much (if any) runtime overhead, and it can allow for type-specialized collections (e.g. a specialized collection instead of the generic ArrayList<Int>).
On the other hand, in languages like Java or C# (the niche it aims for), because the language is actually quite dynamic (compared to Haskell) and has casts you need reified generics to stay type-safe, type erasure is too easy to bypass to be safe (GHC implements generic collections via type erasure, but that's not really an issue in haskell)
You need to generate a type for it at compile time, but I expect there's not much (if any) runtime overhead, and it can allow for type-specialized collections (e.g. a specialized collection instead of the generic ArrayList<Int>).
On the other hand, in languages like Java or C# (the niche it aims for), because the language is actually quite dynamic (compared to Haskell) and has casts you need reified generics to stay type-safe, type erasure is too easy to bypass to be safe (GHC implements generic collections via type erasure, but that's not really an issue in haskell)
> -It uses farmiliar curly brace syntax. And does so consistently.
Not quite consistently, semicolons are optional: http://confluence.jetbrains.net/display/Kotlin/Grammar#Gramm...
The rule is "newline or semicolon", so whitespace does carry a meaning.
IMHO this is a mistake, because it is often fragile and can lead to code that the compiler reads differently than the human sitting in front of the screen.
And yes, I maintain that that's a mistake in javascript and Go too.
Apart from that, I agree with your conclusions. I'll try it out as soon as they release the compiler.
Not quite consistently, semicolons are optional: http://confluence.jetbrains.net/display/Kotlin/Grammar#Gramm...
The rule is "newline or semicolon", so whitespace does carry a meaning.
IMHO this is a mistake, because it is often fragile and can lead to code that the compiler reads differently than the human sitting in front of the screen.
And yes, I maintain that that's a mistake in javascript and Go too.
Apart from that, I agree with your conclusions. I'll try it out as soon as they release the compiler.
JavaScript automatic semicolon insertion is definitely considered to be a mistake (judging by es-discuss), but many many other languages allow newlines as statement separators without problems. It seems to be fine as long newlines are only allowed under certain circumstances within expressions, such as only in grouping constructs () [].
[deleted]
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
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
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...
This looks like a language I could enjoy programming in, overall. The explicit goal of being simpler than scala sits well with me.
- 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...
This looks like a language I could enjoy programming in, overall. The explicit goal of being simpler than scala sits well with me.
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.
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.
I wonder how this works, if it is compatible with generic classes defined in Java and if they optimize the implementation for primitives.
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.
yeah, but where's the tooling? ;)
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.
I think the ;) was an indication of that being a joke.
I must be up past my bed time again.
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?
Here is a comparison: 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
Personally, i don't see a convincing reason to switch. Though absence of type erasure is nice
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.
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.
Dude, read the fucking docs before passing judgment.
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+I...
Then, it also has syntactic sugar for the Delegation pattern:
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+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
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.
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+I...
Then, it also has syntactic sugar for the Delegation pattern:
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+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
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.
I particularly like their much simpler approach to null-safety. Null is a ghost that haunts every imperative language, and it's great to see a good solution. Scala's is also nice, but wordy and difficult for newbies.
Simply being able to call a method chain without null checks or pattern matching is really nice. In Kotlin, you can either declare the variables non-nullable or use a safe call chain, e.g.
kennel?.mommies?.puppies()
http://confluence.jetbrains.net/display/Kotlin/Null-safety
Simply being able to call a method chain without null checks or pattern matching is really nice. In Kotlin, you can either declare the variables non-nullable or use a safe call chain, e.g.
kennel?.mommies?.puppies()
http://confluence.jetbrains.net/display/Kotlin/Null-safety
Unfortunately I can't find a way to download and play with it.
The first public release is pencilled for the end of 2011.
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.
"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...
This is an odd decision, puts me in mind of Yegge's rant -http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-50...
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?
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.
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.)"
"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.)"
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.
You have to mark methods as virtual - I believe classes are by default.
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.
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.
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...
It'd probably be easier to convince a workplace to use this over Clojure too...
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.