Project Kotlin - a statically-typed JVM language developed by JetBrains
confluence.jetbrains.net
confluence.jetbrains.net
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.
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)
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.
- 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, ...
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.
- 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.
I wonder how this works, if it is compatible with generic classes defined in Java and if they optimize the implementation for primitives.
This is an odd decision, puts me in mind of Yegge's rant -http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-50...
"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.)"
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
Personally, i don't see a convincing reason to switch. Though absence of type erasure is nice
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.
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.
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()
code a little Fantom, Gosu, Nemerle,
and some Ceylon when it's out
and some kotlin (ditto
It'd probably be easier to convince a workplace to use this over Clojure too...
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.