Thursday 21 July 2011

Kotlin and the search for a better Java

Another day, another new JVM language. This time Kotlin.

My first point here is that another group is willing to go public and say that Scala is too complex. It is easy to miss this, but anyone writing a new language right now (Kotlin, Ceylon, Gosu, Fantom, ...) is implicitly saying Scala isn't right. Of course I don't expect Scala supporters to like this or agree with it, but the truth is that I and many others have looked at it and run fast in the opposite direction.

As I've commented before, my dislike for Scala is not support for Java. There is a lot wrong with Java, and that cannot be sorted out without breaking backwards compatibility. Elements like primitives, arrays, wildcard generics and basic operators like equals. That is why I have proposed a backwards incompatible Java - #bijava.

More generally, my position is that as a community there is a role for a popular, statically typed, industrial, Java-like langauge without Java's warts. The Java-like also means a design that manages complexity and is usable by the mass-market. Fantom, Gosu, Ceylon and Kotlin are targetting that market. Groovy, Clojure, Scala and many others are simply not targetting that specific market.

I can't comment that much on Ceylon as it is more vapour than reality and from the little public information appears to have some dubious design decisions, especially around verbose words rather than syntax. I've also not studied Gosu much for some reason, yet in a day I've looked at Kotlin a lot (not sure why Gosu doesn't excite me...).

Fantom is probably the most different of the four. It provides a new platform, which happens to run on the JVM (and in the browser via Javascript!). The core Fantom library is new and dedicated to Fantom, with some different design principles to those of Java. It also runs its own form of bytecode, allowing deep immutability, non-null types, full modules and reified generics amongst other things. In fact, one could question whether Fantom fits into the group of four at all, however it does fit the criteria of statically typed, industrial and Java-like.

So, what about Kotlin? Well at first glance it gets a lot right, starting with null-safety and type inference. However, I have real issues with some features, which I think a proper Kotlin blog piece should focus on.

More generally if I could wave my magic wand, I would probably wish that Ceylon and Kotlin would merge into a single project. (Gosu and Fantom are now used in production, and Fantom has many different goals, so both are harder to change now.) Basically, we need the energy of all that input (and associated money) but with a better, single focus. Both Ceylon and Kotlin are still mostly paper languages, and both are trying to achieve the same thing (with Kotlin looking closer than Ceylon at this point). RedHat and JetBrains could you please have a conversation? (I'm happy to mediate if desired.)


I still like Fantom and I think most people hugely underestimate it, especially those from a Scala background. Fantom's rethinks what a language should be from the platform/productivity perspective with deep immutability, deep modules, no shared state and a practical type system that aims to eliminate bugs not be in absolute control. Scala is in many ways, light years behind Fantom.

And this is my key point with Kotlin too. Simply focussing on syntax is worthy, but kind of misses the point. Syntax exists simply to express the programmers intent in a way that should be readable years later. What makes a bigger difference are the productivity issues that are not typically thought of when talking about a language - versioning of code, which logging library to use, how to access configuration or injected state. Kotlin tackles the syntax parts pretty well, though not perfectly. But its not clear yet if they can grasp just how unimportant the syntax is relative to language related productivity gains.



    I can promise that it's more than vapourware and that we're working hard to get a first version out and finally open up the project to the public.

    I do think we would be interested in knowing which things bother you about Ceylon's design, who knows, you might convince us :)
    (Important language design decisions are still being made)

  2. I commented on this notion of complexity of scala so will not repeat myself:

    Hmmm.. it seems like the url isn't even hyperlinked so I am forced to copy+paste the relevant bits:


    And let me be clear: complexity isn't a problem of scala. It just holds the mirror to you and that in turn reflects the average devs persona corrupted by years of J2EE/Hibernate/Spring imperative-getter-setter-mutable-1000-line classes.

    Design by types and functional programming distinguishes the chaff from the grain.

    This might sound abrasive to some but truth indeed is bitter. And hope it makes devs do a serious rethink and form their opinions by actually experimenting and not on gossip.

  3. Patrick Wright21 July 2011 at 11:34

    Hi Stephen

    How much Scala code did you write before you "looked at it and [ran] fast in the opposite direction"? Is any of that code open source? My experience following supporters/detractors of Scala is that a good percentage of those who approach it with trepidation (because of the _apparent_ complexity) are convinced after actually using it that it's a very good language and not as complex as it appears at first sight. That isn't true of everyone, but there are no universally popular languages in general. So how much time did you spend with it before you gave up? Since you're seem to feel Scala is not the correct choice, why not walk us through a project or two you worked on and describe the actual problems you ran into? It might help us understand where your priorities and desires lie - in the context of coding, not just musing.


  4. I'm actually wondering a bit about that "Scala is sooooo complex" sentiment. From my expereince Java is much more complex than Scala, especially for beginners.

    I wonder if the "Java community" will ever come off their high horse ... to some people _no_ language can be made acceptable and I promise that those today who say "Scala is so complex, take Kotlin!" will be exactly those who say in 5 years "Kotlin is so weird, take Blub!".

    So if people are willing to throw away a language with ten years of bugfixing, a stable compiler, a mature library and solid tooling because some vapourware looks slightly more promising to them ... I can't help them. Good luck.

  5. Is it really fair to call this "little public information":

    It's somewhat comprehensive, I would have thought. Sure, some details from the spec are missing, because of the more "tutorial" style presentation, but OTOH I doubt many people are truly interested in reading the whole 125-page specification at this stage.

    And I assure you Ceylon is definitely not a "paper language".

  6. Hi Stephen,

    The link to Ceylon is not correct. is cybersquatting I think.

    I'd recommend people go to for Ceylon news and progress and for an deep introduction.

    And yes we're working on the web site :)

  7. Stephen Colebourne21 July 2011 at 15:49

    Glad to see that Ceylon is alive and that there is more public info than I had previously seen (although the "In relation to" website is dog slow right now). I'll try and review more at some point, but I'd still really like JBoss and JetBrains to have a friendly chat and work something out...

  8. I hope this won't turn into another Scala-is-only-as-complex-as-you-make-it debate, which seems to be the norm nowadays. The fact is, Scala fails at convincing a relatively large amount of professionals including myself, so there really *is* a valid search for a pragmatic no-nonsence language. Please allow this debate without detailing it with comments about how great Scala is.

  9. Whatever might be the merits and flaws of Java, Scala, Ceylon, Fantom or Kotlin. If nobody's using a programming language, these discussions are academic.

    We will see what the future brings ...

  10. That may be, but the Scala, Ceylon, Fantom, Kotlin teams are all hard at work trying to build the next generation language for business computing that *you* may one day find yourself being asked to use. If you decide not to get involved in these "academic discussions", please don't complain if the "future brings" you something you don't like.

  11. When you ran away from scala, was this from the perspective of a language for yourself, or a language for a team/company? If the latter, what size of team and what it the concerns for how the team would cope that affected your decision?

    Genuine question: I'm interested

  12. @Casper: Please allow this debate without comments about comments about how great Scala is. You probably have your reasons for not being enamoured with Scala. Likewise, others (such as myself) have their reasons for pointing out why they think your implications that Scala is not a pragmatic no-nonsense language are wrong. Nobody's trying to discourage anyone from creating a better language, or from debating the point. Cheers, Erik

  13. Brian Schlining21 July 2011 at 18:44

    When I first saw Scala, I also fell into the 'Oh God, it's so complex' camp. I think part of the problem was that the Scala samples being shown on the the Scala web site and blogs were from developers trying to show how clever they could be. Which was just off-putting for newcomers to the language. However, I just finished writing a fairly large project in Scala and I've come full circle and now I think the language is simply brilliant. Personally, I think it's great that groups are exploring new languages on the JVM; if Scala, Fantom or Kotlin rock your boat, enjoy 'em.

  14. A programming language is just a small part of an ecosystem, with it's libraries, runtime platform and tooling.

    JetBrains has a good point. That's not the language is better or any argument like that, no. That is they have a good IDE, an can ensure that their language will be well supported by their IDE, making the tooling for the language great.

    For the library/platform, they have the JVM. What that mean is they can have a productive platform available for their solution very fast.

    For the complexity point, let's face it. Many don't like to change language anyway, and many don't like to learn new things. That's why a better java is all most want. Source compatible, if possible.

    The thing is Sun was just a little more pragmatic we would have Java 8 available for at least 2 or 3 years and all thoses nices features of new language would interrest very few.

    If the problem was to choose the better language by themselve, we would use haskell, or lisp and nobody would even think develop in something as limited as java.

  15. None of these languages are going to be get much traction simply because there's too much Java code in large companies and on large projects and most companies are not going to invest resources to switch to Ceylon/Scala/Kotlin/... just because it's "cool". It's technological imperative approach, doing something for the sake of using a new technology. Just look how many blogs and whatnots are out there titled "How Convince Your Boss to introduce [Scala/Groovy...] into your project" or variations on the same theme. It just won't happen unless there's a compelling business need to do so and there isn't. Most people don't work at Twitter who had a specific need that had to be solved with the specific language. What is Ceylon going to solve? Absolutely nothing. Groovy? Good for writing test because of duck typing and if you are starting out and using Grails great. But all these new languages are dying to get wider Java audience and that is simply not going to happen. If languages like Scala and Groovy cannot gain better traction than they are currently getting what is Ceylon/Kotlin going to do for us? I can tell you what - it's going to make some money for NFJS guys that are going to spend 2-3 hours reading through the docs and examples and then they will "teach" the wider Java community at NFJS/JavaOne/... on all the benefits of using this new language, there'll be more blogs on "How to convince your boss to switch to Ceylon/Kotlin..." and that's where that will all end. None of these languages stand a chance for wider adoption simply because there no one is actually looking for a silver bullet. Everyone seems to think that there is a need for a language to replace Java which may absolutely be the case but I think all people that involved in creating Ceylon/Kotlin better be doing it for the love of hacking or for potential to make a little $$$ on the conference circuit cause that's all that their language will ever be.

  16. You write: "There is a role for a popular, statically typed, industrial, Java-like langauge without Java's warts"

    Fair enough, but I am afraid that "popular" is a tough criterion. Look at how you approach it. Gosu doesn't "excite" you. Ceylon has "verbose words". Scala is "too complex". It's not easy being popular.

    Scala has one huge disadvantage over Ceylon and Kotlin right now. Everyone can download it, try an example, make a typo, get confused by some error message, say "Oh my, my head hurts", and write a blog about how complex it is. I look forward to the release of Ceylon and Kotlin, so that they can be fairly compared to Scala.

  17. I think Cay is exactly right. Let's compare again when Ceylon and Kotlin are available. I think they both can be great - so far everything Gavin has done was awesome (Hibernate, Seam, CDI).
    Scala is already here and you can be very productive with it.

    @Cay: I am sure your upcoming book will help a bit to get rid of the "Scala is too complex" myth.

    And what is success with a language? No language around today will be as popular as Java. But if a language like Ceylon or Scala will get the marked share of Ruby (which is MUCH smaller than Java) then it will already be a HUGE success and I think Scala definitely has the potential to do so and very likely will be as successful as Ruby. And Ceylon or Kotlin may well be as well.

    Just my humble thoughts.

    Markus (who will continue to improve his Scala skills instead of complaining about it).

  18. Stephen you've been asked a couple of times to explain your experiences with Scala a bit more and illustrate why you feel its too complex. You failed to do this and instead just asked people not to start a "I love scala" thread.

    PLEASE tell us your story so we can judge whether you are talking from experience or a paper based analysis of the language.

  19. My opinion is that the most part of the so-called complexity of Scala is the actual complexity of the underliyng concepts : functional, Pattern-matching, traits ...
    And these concepts will also be present in Ceylon or Kotlin, and even in the far future version of Java.

    There are only a little number of wrong things in Scala : some keywords are too short and not explicit, and the implicits whose use make the code being difficult to read.

    Actually, Scala was the first JVM language with these concepts and there was some mistakes. OK. Is it worth doing some new languages and communities and learning for programers just for minor modifications, instead of being involved in Scala to improve this ... I don't think it is very positive.


  20. Complexity doesn't equate difficulty. Scala is ready for the industry and scales very good to large projects. It can perfectly interoperate with Java, so there is no need to start with an empty code base.

    Of course, if you come from Java and your attitude towards a new language is to learn it in a few days with as much Java mindset as possible, you are going to be frustrated. But with any other attitude, I think you will find Scala to a very clean and clearly designed language.

    At the moment, I am waiting for convincing arguments that Kotlin offers anything _substantial_ that Scala doesn't. You have extension methods instead of implicits, ok. But as Martin pointed out, this might be a very short sighted design decision -- let's see how that plays out (you will need to wait a few years by the way). You have non-nullable by default, ok, this may be an advantage when using Java libraries, but otherwise not. The company will provide a first hand IDE - ok, but the IDE situation for Scala is quite good now, and you won't be locked in with IDEA, you can use Eclipse or Netbeans, too.

    So... Although it's good to have more JVM languages, I'm pretty unexcited at the moment.

  21. Christian Essl22 July 2011 at 22:16

    I also found scala a bit complicated, because I was always mixing the OO with the functional style and right found my place.

    So I was looking for a staticaly typed functional language simple as Clojure but well staticly typed and finally found yeti. It's an ml like language for the JVM.

    Realy simple and very powerful. Maybe you want to take a look: and here for the documentation:

  22. " unimportant the syntax is relative to language related productivity gains"

    I think syntax is hugely important. Otherwise, we'd just keep shoe-horning new features into java....

    I wish Ceylon, Kotlin, etc would copy some ruby/groovy features. Where are my list/map/reg ex literals? Where's my collection.any closure or my map.each{key, value}? or a ||= b?

  23. Stephen,

    I think I know what you are indicating regarding your evaluation of Scala. I, too, have now been investigating and playing around with Scala for +6 months. At first, I was quite enamored with it. Then came the phase where I was trying to move beyond learning it to producing effective code with it. That has been quite challenging. In fact, it's been confronting enough to have me actually give pause and doubt my skills as a software engineer.

    The psychological contrast of being very skilled at Java (+14 years of experience) and my not even having mild intuitions around Scala, its libraries and its “simplification-stacked-on-simplification syntax/semantics” has made it very difficult for me to stomach this transition. There are times I will read a Scala blog entry and feel completely lost (and I mean deer-in-the-headlights-what-the-hell-is-a-monad lost). I don't have this undesirable psychological experience when I read the Java blogs.

    To address this, I am eventually going to write a blog post about how difficult it is for a “safe” average Java software engineer to feel quite “challenged” when attempting to make heads-or-tails of Scala. I am in the middle of experiencing it right now and am writing about it (using as my basic theme at the moment).

    However, I have put in enough effort and done enough research of other languages (Clojure, Haskell, Erlang, Gosu, Ceylon, Groovy++, etc.) to now be convinced that Odersky's Scala has some very well thought out subtleties. And although not perfect (no language is or ever will be), the maturing process the language has had over the 9 years it has been available has been quite remarkable. The core principles driving Odersky and company remind me of those driving the creator of Eiffel, Bertrand Meyer. However, Meyer and his language appears to have gotten stuck in the early 90s whereas Odersky and his language continued to adapt and mature. In a word, there is a damn near perfect balance of idealism and pragmatism in Scala that I have not seen achieved in any other language I have evaluated.

    And it is this subtle (and not so subtle balance) Odersky has struck and continues to lead which causes me to “trust” Scala's future. It's the same thing I saw with Java back in 1997. BTW, I feel a similar way about Clojure's originator, too. However, it's Odersky's resume with Sun combined with his clearly identifying both OO and FP as important (neither is more than the other), which has pushed me to Scala and away from Clojure (although if I weren't doing Scala, I would almost certainly be doing Clojure).

    In summary, I think there are lots of people who expect Scala to strike them in the say way Java struck them a decade ago. And for some, perhaps that will happen. However, my experience isn't lining up that way. It's take more resolve, commitment and focus on my being a better software engineer to psychologically put me in the space of persisting with Scala. And I think I have rounded the first of many corners in becoming a more accomplished software engineer with Scala.

    I would recommend you reconsider your position on Scala from a psychological standpoint as opposed to what appears to be a very facile evaluation of Scala and the other languages which appear at first to be nearby. I think when looked at a more principled and deep level (which includes many practicalities), Scala stands way out from it's released “competitors”. I will have to wait and reserve judgment on those competitors that have not matured to a “production release” yet. They get to be pie in the sky. They also get to be judged (by me) as not mature and unlikely to compete with Scala on any reasonable basis for at least a couple of years.

    Here's to hoping you find it acceptable to be confronted by what appears to be Scala's complexity, but in fact is just effective elegance. Best of luck.

  24. No mention of Mirah?

  25. Also, no mention of Fortress? Admittedly it seems to be at alpha stage right now so it may be a while before we can use it properly. It looks as well thought-out as Scala but (arguably) much simpler, runs on the JVM, and has ditched as much syntactic baggage as any language. Don't think it's for scientific computing: that's just a cover story, it's general-purpose. Guy Steele is thinking far into the future how programming should be, & to me it feels more like the future than anything else.

  26. 'PLEASE tell us your story so we can judge whether you are talking from experience or a paper based analysis of the language.' communist, witch hunt, Spanish Inquisition...

    It doesn't matter, as long as it is the perception of a large group, it will stifle adoption rate.

    Not sure why you are all wacking away at it.

    Fortress seemed interesting but progressing at a really slow pace though considering the 'market' they are targeting it might be important to get it right the first time(tm)

  27. @Jim: I think you do the right thing by having a humble and honest approach to Scala, which is the right way to approach a completely new language (this is not a "better Java"). I hope the Scala community will benefit more and more from your blog and similar ones, thanks for this.

  28. why not mentioning c# ?