I've been using Kotlin on Android for about six months, and can't recommend it highly enough. If you're stuck in the Java ecosystem, Kotlin will make your life much better.
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 language is promising, but given the incredibly fucked-up state of the Android build tooling merely getting to the point where you can evaluate Kotlin is an exercise in extreme patience.
> 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.
Build times are used to be slower, but I think recent Kotlin compilers have "daemon" mode to speed things up.
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).
I also highly recommend Anvil. Anvil + Kotlin makes Android development feel sane and at times even joyous! I should write a blog about my experiences.
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've been using Kotlin for a little while, as the backend language for the side project/maybe-startup I'm working on. I went with it because of my troubling tendency to write Scala code I can't read three weeks later, and in that I think Kotlin's a big success: the Java interop is good (still some weirdness around DI frameworks and non-nullable types, which is unavoidable if you're using something like Jersey with HK2), the language itself has most of the niceties I want, and I find that the tooling is really pretty good in general. And the Kotlin community, in my experience, has been really good (aside from...sigh...yet another Slack chat to be in), unlike the continuing and perpetual disaster of Scala whenever certain members of the This Should Be Haskell mafia are allowed near anyone who's just asking a question.
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.
That's helpful. I have this side Scala project, a long-lived daemon[1], that I've been meaning to rewrite in something else, as I've grown disenchanted with it. (Bruce Eckel and Paul Phillips contributed to that. [2]) But every alternative I could think of was not so appealing. I'll check this out.
I tried Kotlin in one small project, which used Java API and I can recommend it. There are a lot of handy features there.
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.
Kotlin seems to fill a niche comparable to TypeScript: a language that doesn't try to break new ground, but picks a bunch of tried-and-true ideas to fix severe problems in the underlying platform. Like TypeScript, I hope that it ends up being the right language, with the right compromises, at the right time.
How is it better than Ceylon 1.2? Ceylon compiles to JVM bytecode, JavaScript, Dart, and will to LLVM in the future. As a language, it's a great superset of Java.
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!
Well, the community here basically discussed the topic in detail 2 days before, when Gavin announced the 1.2 release[0].
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.
Not better -- different. In my opinion, it's best to read the two language's design goals to understand the difference (as those matter a lot more than any particular feature). The Kotlin design goals are outlined in the blog post, and the Ceylon design goals can be found here[1]. IMO, a TLDR would be: Ceylon attempts to replace not just the Java language but also the standard libraries, while Kotlin intends to upgrade the language only and blend into the existing ecosystem. That difference explains many if not most of the decisions regarding the particular features of each language.
Kotlin has a real potential to replace Java for Android, since Android is stuck with Java 1.6. I think a lot of this buzz and excitement comes from the Android side.
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.
> Ceylon. As a language, it's a great superset of Java
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.
Don't know Ceylon or Kotlin except superficial poking around the websites.
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.
Given that a strength of Kotlin is that you can dumb-port Java straight to it without even thinking about it, I'm not really surprised it doesn't have much presence on Rosetta Code. It's not the right audience.
Especially after looking into this: http://rosetta.alhur.es/compare/Ceylon/Kotlin/#
which another guy posted here, it's pretty clear that NOBODY wants ceylon.
Why? Syntax.
Scala, Kotlin are loved by many cause of one simple fact. Their syntax. Ceylon tries to do something very differntly, which many people won't like.
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.
android! compiling to javascript, dart and llvm are all nice-to-have; there are tons of good languages that do that. there are very few good languages for writing android code, and from what i can tell, kotlin promises to do it with the fewest tradeoffs in performance, app size and tooling.
Kotlin has a much simpler syntax, and much simpler semantics, than Scala. Specifically, it's largely a very, very good syntax, and small class library extension, for otherwise-vanilla alternative syntax to Java.
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.
Just to clarify, Kotlin doesn't have a collections library. What it does have is some clever compiler magic over JDK collections that adds:
• 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.
Eh, I get why my phrasing might make it sound like they had a totally separate collections hierarchy; you're right, they don't. But I'd count the changes you list--especially the extension methods, which basically provide an entire Java 8-streams-like API that runs comfortably on top of even Android's superannuated Java--as a collections library in its own right. (Hell, even the fixes they do at the compiler level to maps makes the entire collections API feel a lot more like .NET, with its reified generics, and a lot less like Java's weird situation.)
There are many feature-level differences, but the biggest differences are in the approach, goals and philosophy[1].
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).
You keep spreading your misinformed FUD about scala every time someone mentions it in a thread. Do you really continue to maintain the position that scala is not used successfully by large teams?
Pron tends to zealously defend Java and Kotlin and bash pretty much anything else, especially Scala, but his post here today seems perfectly reasonable.
The only thing that seems to be spreading is the use of the word FUD as well as personal attacks by some people who think they should be rude to those they disagree with. A few conditions have to be met in order for a statement to qualify as FUD: 1/ It has to be false or at least grossly inaccurate, 2/ its falsehood/inaccuracy has to be intentional, and 3/ it has to be negative. My statements fulfill none of those conditions, so relax. It's been a long time (well over a year, if not two, IIRC) since I discussed my bad experience with Scala or said anything negative about it, and for the record, I have never said that Scala is not used successfully by large teams, only that I have had a very bad experience adopting Scala in a large team, an experience shared by other such teams, and that I believe it may not be a good choice in such circumstances. My opinions are neither overly negative nor uncommon, the only difference is that I was foolish enough to sound them in spite of the rampant rudeness of some who for whatever reason took personal offense. I have also repeatedly said that I realize that that experience isn't universal.
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).
I'd say the syntax is halfway in between Java and Scala. That makes it much more approachable for Java developers (you can learn the basics in an afternoon), but also less flexible than Scala sometimes.
Yeah, Kotlin looks largely like a simpler, stripped down version of Scala. It's a lot closer to Scala than it is to Java, but it's close enough to Java devs to not have to put in much effort to learn vs learning Scala. I prefer Scala, but not everyone wants to invest the time to learn it in order to gain maybe 25% more expressiveness. Kotlin also seems like a better fit for Android than Scala (and Java for that matter).
In what sense is it closer to Scala? It's more like a slightly nicer Java: All Kotlin code can be translated back to Java (with some boilerplate), but almost no Scala code could be expressed gracefully in Kotlin (or Java).
Not everything in Scala can be cleanly translated into Java, but Kotlin looks more like a subset of Scala than it does a superset of Java. The syntax is very close.
Much faster. So very much faster. I won't trade off so many features for compile speed as to make Go seem like a good idea, but Kotlin is hitting a really nice balance for me between Java and Scala on the feature/iteration-loop front.
Which is mostly what used to be, 10 years ago. Closures, map, fold, etc. Before Haskell and Clojure like immutability and extra trimmings became fashionable...
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...)
Quite right, back on those days FP was Smalltalk (yes really), Scheme, Common Lisp, Emacs Lisp, Caml Light (no OCaml yet), Standard ML and Miranda (no Haskell yet).
Which like you mention is where I point those hipsters to.
Then again, all new generations think they know best.
FP doesn't even have a definition (though pure-FP does, but it, too, can be a bit ambiguous and depends on how you define effects). FP is mostly accepted to be those patterns practiced by people in the FP community. I heard someone deeply involved with FP say, "FP is more a community than a well-defined programming style".
Sequence has much the same extensions available on it as other collections.
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.
I've used both Kotlin and Scala a bit and for some very specific message passing/protocol tricks, Scala was able to let me do what I wanted more than Kotlin. That was maybe 6-12 months ago, so I'm not sure if that has changed.
That said, there is something pretty cool about Kotlin that I like. Congrats on 1.0 Beta.
are non-exhaustive pattern matches in kotlin warnings, errors, or neither?
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."
> 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
This looks to be single value matching only and no compile time exhaustion checks. This looks like really nice (i.e. sugary) alternative to switch but not quite pattern matching.
It's an error only when the 'when'-expression is used as a value, like assigned to a property, passed as an argument or returned from a function. Otherwise it's not an error. There's also a warning for matching enum values over an incomplete set of enum entries, but otherwise non-exhaustive 'when'-expression is green code.
You can basically consider 'when'-expressions to be syntax sugar over Java's if-else or ternary operator (?:) chains.
No, as I mentioned, only those 'when'-expressions, the result of which is used as a value, must be exhaustive. Those which are not, we call them 'when'-statements, correspond to an if-else chain in C-like languages and thus are not required to be exhaustive.
They have taken steps to separate (most) of the frontend and the backend and will be resuming work on the JS side after 1.0. While I haven't dug into the internals very much, it seems with the concept of "platform types" (i.e. implicitly nullable) and not having anything too JVM-specific, CLR support might be an approachable project for the community. I recommend the community take it and keep it up to date with pre-releases of Kotlin. With ScalaCLR IIRC, when Typesafe decided to stop supporting it it basically withered as new Scala features were rapidly developed.
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).
Right now developing a new backend for Kotlin is much harder than necessary because the compiler doesn't have any IR and any desugaring passes - in other words, each backend has to work directly with the full AST (annotated with types etc., but still using all language constructs).
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.
we still hit a great but since we support legacy printer devices on our applications which using ssl over a custom certificate which changes over every printer.
So we would need to have a function that accepts any cerificate inside the ws-client of play. unfortunatly the acceptAllCerts doesn't work in play 2.4+.
however we didn't hit more bugs, yet and using it since 2.1
I'd imagine having Jetbrains behind Kotlin means much better tooling, which is likely to be more important for a lot of people than language features like ADTs.
to be fair, I presented that before Kotlin hit 1.0. A few things that I liked are no more (like the @-less syntax for annotations). But all in all I believe it is still a good commentary.
I'm disappointed with the people who are down-voting this comment, as it's, in my opinion, informative and provides a reasonable summation of the differences between Kotlin and Scala.
I'd ask people who disagree to put their disagreement into words.
So what, in the above "wall of text", is wrong about Scala or Kotlin? You're not telling what was incorrect, just that the author is _always_ incorrect, which strikes me as hyperbole.
It's just the regular Scala brigade that stalks and attacks anyone who dares criticize Scala, regardless of the content of the criticism. They seem to have become extra sensitive with the recent momentum that Kotlin has been gaining.
If you were wondering why the Scala community has such a bad reputation, it's because of people like them. Just ignore them. Fortunately, not all Scala users are like them.
Can you make a contribution besides booing from the sidelines? It just so happens that gavinking misunderstood my statements, and then it turned out that we were in agreement all along (at least about the facts), and NONE of my statements about Ceylon turned out to be wrong in that discussion. If you believe I'm wrong about something -- please state what it is that you think I got wrong (preferably without being rude). Because you have never done so, and when gavinking did, it turned out he had simply misinterpreted my comments, so you're second-hand quoting from argument that was nothing more than a misunderstanding. Your personal attacks on me are ridiculous and unfounded and have no place here on HN. I'll ask again, have I done anything to offend you that you feel the need to so blatantly violate HN's code-of-conduct?
You may have accidentally confused the characters. It wasn't me who was told by Scala's designer my facts were wrong (that never happened; well, I'm sure I've got many facts wrong in my lifetime, but Martin Odersky has never called me out on any), but you, and only 3 days ago. Not only did he find you wrong but also rude, and as someone who actually tries to correct a true inaccuracy, he pointed out quite specifically (though very politely) what you got wrong[1] rather than just yelling FUD as some other people do whenever someone voices an opinion they don't like to hear. BTW, I can attest to modersky's statement, as I personally witnessed him and Andrey Breslav talking and exchanging ideas on more than one occasion.
As to gavinking, well, he and I have rarely seen eye to eye, but he, too, hasn't pointed to a factual error on my part. Now, you can make an original contribution to this discussion or not, but you should stop with the personal attacks.
As the Scala tech lead, I'm glad to learn we've finally
adopted "almost every new PL concept!" I guess by now
everyone will recognize your username and adjust for bias
accordingly, but still, how about sticking to the facts?
Sigh. No wrong facts. He (not the language's designer, BTW) just didn't like my use of (obvious) hyperbole. In any case, I really suggest you drop this. I am not an enemy of Scala. Unlike adriaanm's assertion (and that is a false statement of fact), I am not even biased against it. I was an early enthusiast, I gave it a very serious try, and I just really didn't like it. Yes, I think it is not a good language for use by the industry. I am not uninformed, I am not wrong, I have just reached different conclusions from you. So what? I, like many others, just don't like the language, and we all have very valid reasons to, just as those who do like it have their own equally valid reasons. Do you know how many people don't like the languages I like? You know how many of them find those languages unfit for use by the industry? And many of them are much more hostile in their objections than I've ever been. However, they, too, have very good reasons not to like them, while I have very good reasons of my own. If you go on a personal attack against anyone who doesn't like the things you like, it won't serve your goals in the least.
In any case, I don't mind arguing over language design (politely!) with you or anyone else, and I realize full well (as should you) that it can sometimes be a very personal preference with no wrong or right answers -- just many opinions, many of them valid -- but please keep to the subject and be original.
You're strongly objecting to what he's saying now, but you can't tell me what is incorrect in what he said? Which strongly suggests that you're objecting to the person saying it, not the said.
You've posted dozens of flamewar-style comments about this over the last few days, including many that are bannable offenses, like https://news.ycombinator.com/item?id=10472985. This is unacceptable here and we've banned your account. If you don't want it to stay banned, you're welcome to email hn@ycombinator.com. We're always happy to unban people when they give us reason to believe they'll follow the rules in the future.
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.