The Kotlin Language: 1.0 Beta Is Here
blog.jetbrains.com
blog.jetbrains.com
I also recommend it for people coming from the world of dynamic typing (Ruby, Javascript, Python, etc.). If you can appreciate the guarantees of a static type system -- and I submit that anyone who has worked on a project of more than a few KLOC can -- give Kotlin a try. It's much less verbose than Java, and gives you the tools and constructs to program in much the same style as you would in a dynamic language, but with extremely good compile-time correctness checks. It may not be Haskell, but it's pragmatic, practical and productive.
The tooling is also world class, as you might expect from a language developed by JetBrains. I recommend using Kotlin with IntelliJ -- the intellisense is guaranteed to boost your productivity.
Seamless Java interop has been a huge priority for the developers, so the ecosystem is also quite good. Its biggest weakness (for my use case anyway) is the lack of a good, modern web framework. Hopefully now that Kotlin is more stable a native library ecosystem will emerge that plays to Kotlin's strengths more than Java's.
> The tooling is also world class, as you might expect from a language developed by JetBrains. I recommend using Kotlin with IntelliJ -- the intellisense is guaranteed to boost your productivity.
It's a sad state when IntelliJ can be considered "world class". Sadly, I've had nearly as many problems with it as I have with Eclipse. I've been thrashing about desperately trying to find any production-ready alternatives to straight Java for Android development. I will literally cry tears of joy when I do, but it's not going to be today.
I personally use Kotlin on a daily basis for Android development and build time is comparable to the one of Java. May I also recommend Anvil framework (https://github.com/zserge/anvil)? It brings declarative layouts and data bindings, which works best with the immutable data types of Kotlin (much like React does in the web).
At the moment the gradle plugin doesn't do incremental compilation. If you use it for Android, that's an issue because of the Android build system.
I use Kotlin for free standing programs that run on my laptop/desktop. In these cases it's about as fast as Java, but that's because IntelliJ controls the compilation itself and gradle/maven is used only rarely.
I miss things from Scala once in a while, but they're usually me being way too cute with my code anyway--good for tiny personal things, not for something I'm hoping I'm looking at three years from now, not just three weeks from now.
There were quite a bit of breaking changes, but, of course, it's expected from unreleased language. It wasn't hard to fix things.
For me Kotlin is in sweet spot between verbose Java and complex powerful Scala. From a practical point of view, I would prefer it to both. Any competent Java programmer will catch Kotlin fast enough, and it has almost anything I would want from a "improved Java" language.
I posted [0] about the great new Ceylon 1.2 (which is backed by Red Hat), and nobody seemed to care, but there's so much hype about Kotlin - I don't get it!
Now, on why things are the way they are currently, here are a couple of reasons.
- so far, the ceylon team focused their efforts on the language itself and less on the available platforms, and that's why there are no clear getting staring guides for basically anything: web, android, etc.
- the language itself has a very distinct feel: from the way you publish your api (using the shared annotation), to the way union types affect the language (new way of handling errors, etc) to the way you use iterables {String*} instead of lists. These are all great features, but until you get the hang of it, they feel different. For me, this is just a problem of documentation.
- There is a very strange misconception, for lack of a better word, that just because JetBrains is building a great kotlin IDE, the ceylon IDE is somehow lacking. Which is not true at all. The eclipse plugin works great, and they'll also have an Intelij plugin soon.
[1]: http://ceylon-lang.org/documentation/1.1/faq/ + http://ceylon-lang.org/blog/2012/01/10/goals/
Ceylon has yet a solid Android support I think (I could be wrong)
I have not tried on Ceylon so I cannot comment whether it is better or worse than Kotlin.
You're using the word "superset" quite loosely. A superset of Java would compile Java syntax into bytecode with all the same semantics as the equivalent Java code, as well as bring its own additions, which Ceylon clearly doesn't do. Groovy claimed to be a "superset" of Java but a handful of various syntactic elements behaved differently e.g. the == operator, catching many unawares. It's not introducing any Java 8 syntax changes, its backers flippantly saying "we'll leave them for Groovy 3". They tried to maintain a rough equivalence between the syntaxes for years by using annotations instead of new keywords, then one day its project manager changed "@Trait" to "trait" in a move that reeked of favoritism.
So, let me ask you, how is Ceylon better than Kotlin? I'd like to see a good write-up (separate blog post) that compares and contrasts the two. What are use cases where one language would be significantly better than the other?
(Edit) Wow! Did not expect such a dearth of samples (for both languages) on Rosetta Code.
http://rosettacode.org/wiki/Category:Ceylon
http://rosettacode.org/wiki/Category:Kotlin
and only one overlap:
I mean lets look here: variable value doors = [ for (_ in 1..count) closed ]; nobody even understands this. and this is the first "real" line.
then look at Kotlin: val doors = Array<Boolean>(100, { false }) everybody will understand what it does, you don't even need to know kotlin.
Doesn't seem too bad coming from Python with list comprehensions.
This is the whole reason for its existence: Kotlin code cleanly interoperates, in both directions, with existing Java code. From my own experience, this means that it's very easy compared to Scala to introduce into an existing code base: you can sanely go class by class, file by file, cleaning up code, relying on the existing unit tests, without breaking anyone's workflow. As a result, it has, in my experience, proved a lot cheaper than Scala to train new devs in it as well.
That's not to say that it's all just syntax, though. Kotlin also brings null safety, traits, builders, and some other key things over from the Scala, Groovy, other sources, which has proven to be a major productivity boost. Its collections library is a lot saner (IMHO) than Java 8's due to better generics support. It adds data types and value semantics for when you need them as well. But it does so in a way that (again, based on experience introducing Kotlin into a company after Scala had failed to gain any traction) is a lot easier to teach to most developers, and a lot easier to integrate into existing workflows.
• Mutable vs immutable views (List is read only, MutableList is read/write)
• Safer generics: map[key] which is translated to map.get() has the type bound you would expect rather than Java's much weaker Object type.
• Lots and lots of extension functions to do things like functional programming with them
However, behind the scenes they are still JDK collections, so you can call to and from existing Java with no problems and ... you know, actually, JDK collections library is pretty good. Especially once you get into the scalable concurrent collections.
When it comes to philosophy, Kotlin is a modern Java -- i.e. a "blue-collar" language[2], aiming to adopt only tried-and-true ideas and not to break new grounds. Scala is most certainly not blue-collar, serving as a basis for a few PhDs, and incorporates many ideas that haven't been tried in the industry. Scala is adventurous; Kotlin tries hard not to be.
When it comes to goals, Kotlin aims to solve Java's pain points (nulls, properties, beans) while keeping the same libraries. Kotlin doesn't even have much of a runtime library to speak of. A Java library is an idiomatic Kotlin library, and is almost indistinguishable from Kotlin libraries when used from Kotlin (i.e., no limited functionality, no wrappers needed). Kotlin's design is built around this core idea. While Scala interoperates with Java, it has its own runtime library, and many types (e.g. collections) need to be wrapped when passed across languages.
When it comes to approach, Kotlin is developed hand-in-hand with its tools (IDE, build, multi-lang compilation), and made to be gradually adopted into Java codebases. You can easily mix Kotlin and Java classes in the same package (the IDE will even convert any given Java class to a Kotlin class, and seamlessly handle mixed-language codebases). Scala and its tools are developed separately, and it's built to be independent of Java (although it interoperates with it). Another difference in approach (although it's still theoretical so not quite fair) is that the Koltin dev promise that the language will be source and binary backwards-compatible starting with the imminent version 1.0 (though this promise hasn't been put to the test), while Scala allows for occasional breaking changes.
[1]: Java and C have very similar syntax, yet the two are completely different (although Kotlin and Scala are probably more similar to one another than Java and C).
[2]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....
Also, I would appreciate you stop saying that my opinions are misinformed (as they are most certainly not), unless you care to point out my errors. It's OK to disagree, and I don't think you should expect everyone to share the same opinions with you.
BTW, I think that much of the (valid) disagreement stems from a difference in perspective. Some people concentrate on language features, while I could care less whether a language has higher-flavored emojis or subliminal piping. I view those features as means to an end, so first and foremost I care about that end -- what the language aims to achieve -- long before getting to how it aims to achieve it, which, IMO, is only a concern once the goals match your own, otherwise the discussion is purely academic (which may be interesting in its own right, but not my focus).
In 1995 or even 2000 era LISP discussions you rarely if ever see those other concerns about FP that hipster functional programmers bring forward today.
(I guess it's also something that was helped by Moore's Law style speed development slowing down and the advancements in multicores...)
Which like you mention is where I point those hipsters to.
Then again, all new generations think they know best.
In Scala, to express a recursive parser combinator:
val e = p | e
You can't define such a thing in Kotlin. Atleast, this was the case the last time I looked at it.
val e = p | e
val e = operator_pipe(() => p, () => e)
Note that the operator_pipe() itself returns a function, which gets assigned as a value to `e`. So there is lots of implicit laziness.
And non-lazy map/reduce/filter. Which I almost see as a deal-breaker.
I did a tutorial a week or so ago (it's not online yet, unfortunately) on FP in Kotlin. We wrote a little app to do IntelliSense style autocompletion on an n-gram model. The core code was purely functional and used lazyness as well.
I suspect "does Kotlin support FP" is one of those questions that's doomed to turn into a no-true-scotsman thing: whatever support is available will be considered insufficient by true FP fans :-) But it's good enough to let you write code in a typical functional style in many cases, with little cost.
That said, there is something pretty cool about Kotlin that I like. Congrats on 1.0 Beta.
https://medium.com/@octskyward/why-kotlin-is-my-next-program...
looks like from the docs:
"If `when` is used as an expression, the `else` branch is mandatory, unless the compiler can prove that all possible cases are covered with branch conditions."
So it is an error, I assume?
> What about pattern matching? This is where the word “sealed” above comes in handy; we can do an exhaustive pattern match without an else/otherwise branch
from https://medium.com/@octskyward/kotlin-fp-3bf63a17d64a#.8dbwa...
You can basically consider 'when'-expressions to be syntax sugar over Java's if-else or ternary operator (?:) chains.
So there are no non-exhaustive pattern matches, is what you are saying? i.e. they all must be exhaustive. Except for your enum example
More info in the official reference: https://kotlinlang.org/docs/reference/control-flow.html#when...
Portable code between WP and Android without JNI pain.
It also has a better chance than ScalaCLR due to how small the runtime is. But, like Swift with ObjC, since the runtime is so small so many of the libraries are going to targer the JVM and reference JVM libs which may make the cross-VM ecosystem non-existent (doesn't mean it still won't have good CLR uses of course).
We plan to rework this post-1.0, after which building a new backend will be much more feasible.
But having platform specific code hidden behind interfaces is way saner than having to write JNI for almost every framework API when using C++ for business logic.
The problem doesn't happen in the other mobile OSes thanks to Objective-C++ and C++/CX. My current approach.
https://speakerdeck.com/evacchi/kotlin-and-ceylon-modern-pro...
I can't say I've used Ceylon much but I think Kotlin's syntax is much nicer and it's much easier to approach than Scala.
I'd ask people who disagree to put their disagreement into words.