15 ms·

Why Kotlin is my next programming language (2015)

133 points by insulanian 10y ago

Scene_Cast2 10y ago
I tried Kotlin during the Surprise Language round of Codeforces, a programming competition. I found it to be more verbose than a typical modern scripting language. Maybe it's the result of choosing the least of the evils for what it's trying to accomplish. The other drawback: the documentation. Kotlin's reference documentation (looking up how to properly use a call) does not have any examples. I'm not even talking about full compilable examples - although that would be nice, it doesn't even have one-liner examples. FWIW, I was trying to look up how to use a comparator to sort a MutableArray<Int,Int>.
- rattray 10y ago
  Personally I don't much mind the added verbosity, coming from Ruby/Python/JS, so long as I don't have to write so many damn tests. Speaking from minimal experience, Kotlin still seems like a big net win here. Same is true of other languages with lightweight, static type systems like TypeScript/Flow, Swift, and Go. I agree about the documentation – I think it's one of the biggest reasons the language has seen such little adoption given its benefits. I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. Kotlin is developed by Jetbrains, so of course they're used to IDE-driven-development, and have a financial stake in people using their products for development. But coming from scripting languages, this sort of documentation gap was a real turn-off for me.
  - Bromskloss 10y ago
    What is it that makes you not having to write so many tests?
    - smt88 10y ago
      A decent type system
    - iends 10y ago
      Static typing.
      - Bromskloss 10y ago
        Is the reasoning that you then don't have to test what happens if you pass a parameter of the wrong type to a function?
        bbcbasic 10y ago
        The compiler guarantees it won't happen. Such a test would be a test of the compiler and in my opinion unnecessary. And in Haskell at least... impossible. You can't write the the test because IT won't compile!
        Bromskloss 10y ago
        I understand that. My question is if that is the kind of tests that people have in mind when they say that static typing requires fewer tests.
        bbcbasic 10y ago
        I can't speak for anyone else but I believe so yes.
        iends 10y ago
        Yes. When writing JS you have to explicitly do a lot more validation.
    - StavrosK 10y ago
      Without looking, I'm guessing static typing.
  - eropple 10y ago
    > I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. I would suggest (and I'm not trying to bag on you with this) that this concern is more your unfamiliarity with the JVM than a failure of Kotlin, which is generally targeting Java and Scala developers. Kotlin operates pretty idiomatically in the Java universe and, as an experienced JVM developer who's comfortable with all of Maven, Gradle, and SBT, I dropped Kotlin into a Maven project, side-by-side with Java, with a cursory glance at the documentation--"oh, it's another pre-compile-step thing". (Which I then consume via IntelliJ, because IntelliJ imports Maven projects nicely, but Maven allows others to use their IDE of choice.) The pre-compile-step thing sucks, I'll be the first to say that, and it's a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably. I prefer to use multi-module Maven projects and separate out Java and Kotlin--or Scala, for that matter--code into separate ones. But that's a different beast entirely from the initial bootstrap when learning.
    - rattray 10y ago
      > your unfamiliarity with the JVM Correct! > a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably A bummer to hear – though I'm glad it's not just me. I tried using Kotlin with the Play Framework and did not have a great time. The hot-reloading features of Play didn't work with Kotlin at all, even with my attempts to `touch` a Java file whenever my Kotlin file changed (presumably they're recompiling more intelligently than I was). Perhaps having SomeController.java and SomeController.kt in parallel, where the former imports the latter, and receives a `touch` or similar whenever the Kotlin file changes, might work? Or would you recon such a project to be a fool's errand?
      - eropple 10y ago
        Play isn't built for Kotlin and SBT is kind of a tire fire in general. I would suggest something more like Dropwizard for use with non-Scala JVM languages.
        EtienneK 10y ago
  - meddlepal 10y ago
    I agree the documentation needs work and I am using Kotlin in prod. JetBrains please take note!
    - voddan 10y ago
      Could you please elaborate on what needs improving in the docs? Btw, the whole kotlinlang.org is OSS, and you can correct things you don't
  - winstonewert 10y ago
    What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.
    - sanderjd 10y ago
      Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.
      - dmichulke 10y ago
        I address this problem by checking the type at run-time via an assertion. Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production. Writing specific tests for that looks very inefficient to me but maybe I am missing something.
        bbcbasic 10y ago
        I don't see how this reduces the need for a test that the wrong type is handled correctly.
        dmichulke 10y ago
        The underlying idea is that it shouldn't handle the wrong type at all, it should fail. If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.
        mac01021 10y ago
        And you don't need tests to make sure the assertions are there?
  - cageface 10y ago
    Absolutely. Dynamic languages only seem terse because you don't see all the associated test code inline. I've been programming in a mix of dynamic and statically typed languages for more than 15 years now and I'll take a modern statically typed language over a dynamic language any time if I have my choice. It's a lot harder to design a static type system that's both expressive enough to be pleasant to use and strict enough to be useful. But we're getting there in modern languages like Rust, Kotlin, Swift etc.
  - voddan 10y ago
    "integrate Kotlin files into a Java project without using IntelliJ" - compilation of a mixed project is not a trivial tasks, many things must be set up. A detailed description of this takes a chapter in a book. That's the reason one should use build tools, be it Ant, Maven, or Gradle. The process of setting them up without an IDE is narrowly described in the docs https://kotlinlang.org/docs/tutorials/build-tools.html https://kotlinlang.org/docs/tutorials/build-tools.html
- fierycatnet 10y ago
  From what I understand Kotlin is the language that was designed to be used in house by JetBrains to simplify their Java code. It wasn't born to be the revolutionary, just practical for Java developers.
- voddan 10y ago
  The Kotlin reference is not supposed to be used for finding methods. The way to go is to use auto completion in an IDE. If you type `myArray.sort<ctrl+space>`, you get all one needs, including `sort`, `sorted`, `sortBy` (which you needed). Alternatively you could search the reference page for Array or MutableList or MutableMap, not sure what you wanted: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-mutable-list/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collecti... https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-mutable-map/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collecti...
  - Scene_Cast2 10y ago
    I had something like this: var heights: Array< Pair<Int, Int> > = ... //populating the array heights.sortBy { it.second }; It was not obvious at all that I had to use curly braces. The documentation says: inline fun <T, R : Comparable<R>> MutableList<T>.sortBy( crossinline selector: (T) -> R?) (source) This is after I figured out that I'm not supposed to use sortWith (I never figured out how to use this one)
    - voddan 10y ago
      The curly braces are the syntax for lambdas, one of the basic types `(T) -> R?`. There are plenty of examples for using that, but in the respective chapters: https://kotlinlang.org/docs/reference/lambdas.html#higher-order-functions https://kotlinlang.org/docs/reference/lambdas.html#higher-or... or in this bunch of examples: https://kotlinlang.org/docs/reference/idioms.html#filtering-a-list https://kotlinlang.org/docs/reference/idioms.html#filtering-... The docs are arranged in a way that one reads them in the order they are written (at least the first half). I supposed that would take more than half an hour given at the competition. I don't think Kotlin is the best choice for programming challenges like codeforces - they really don't let him shine (although I use it whenever I can). But if this is a valid case, we can collaborate and write a short tutorial for C/C++ to Kotlin programmers.
    - Scene_Cast2 10y ago
- n72 10y ago
  For those who want docs in the examples, perhaps "liking" my post regarding this on the kotlin discussion forum would help: https://discuss.kotlinlang.org/t/examples-in-the-api-docs/1646 https://discuss.kotlinlang.org/t/examples-in-the-api-docs/16...
komone 10y ago
Yeah. No.
ld00d 10y ago
I really liked Scala when I played around with it (bare with me here), but when deciding on what to use on a project I'm starting, targeting the JVM is a downside. Can I depend on the JVM being on the target machine? If not, I'll have to deal with the dependency. However, if I choose a compiled language like Rust, I don't have to worry about that.
- smt88 10y ago
  Most people writing Java will be able to control the presence of the JVM. Only B2C desktop apps, which are fairly rare these days, will have to worry much about the dependency.
  - ld00d 10y ago
    Unless you're doing JavaFX or something like that.
- eropple 10y ago
  Under what circumstances are you writing software for deployment in places you don't have administration access on (i.e., your servers, which should be deployed with CM as-is and make adding dependencies trivial) where you cannot package OpenJDK (this is trivial on Windows, OS X, and Linux), cannot expect a system administrator to install the JVM, and can expect Rust to run? There is a slice of the universe where this exists, but it's not really Kotlin's target in the first place (and I think that's basically self-evident from everything around it) so I'm not sure why you'd try to jam that square peg in the round hole to begin with.
  - ld00d 10y ago
    I'm thinking of client machines. People balk at installing Java these days. Is there a way to get the JVM without Java? Is Kotlin not capable of being a client application?
    - tormeh 10y ago
      You just package the JVM with the application itself. Create a .bat/.exe/.sh/binary file that calls the JVM with your program as the argument. It's simple, but it will increase the download size of your program significantly (unless your program is huge - then it doesn't matter)
kmiroslav 10y ago
Should probably be renamed "Why Kotlin is my current programming language".
hnxx 10y ago
Kotlin reminds me of coffescript to JavaScript.
- highwind 10y ago
  As far as I know, all CoffeeScript did was add bunch of syntactic sugar on top of JavaScript. I believe Kotlin actually adds programming paradigm that's not in Java on top of terse syntax, i.e. real closure, operator overloading, pure object orientation, and more.
  - lmm 10y ago
    Java already has real closures and pure object orientation. Operator overloading is just sugar.
- ungzd 10y ago
  And also may become obsolete after Java 8/9 (as Coffeescript after ES6/7). Problem is that noone in Java body shops ever touched Java 8, they're still migrating from Java 5 to Java 6.
charlieflowers 10y ago
I am a bit in a hurry, so I acknowledge I only quickly scanned the article. But it struck me as damning by faint praise. Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." No offense intended ... that's just my quick take.
- deleted 10y ago
  [deleted]
- jkot 10y ago
  > If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." I think that is wrong approach. Kotlin has nothing special or innovative, everything was already here. But it is well balanced and industrial strength (something like java). It is simply good workhorse for most tasks. It is excellent replacement for java, that is all.
  - reality_czech 10y ago
    Now that JDK8 has made Java more expressive, and Oracle's trolling has come to nothing, I expect Kotlin and Ceylon to fade away. If you want Java, just use it, already.
    - Nullabillity 10y ago
      Java 8 improved things, but it's still far behind the rest. Also, both Kotlin and Ceylon (and Scala and Clojure) would be affected by the Oracle trolling, since they all run on the JVM.
- KaneMorgan 10y ago
  I actually like that it's informational rather than ideological.
Buttons840 10y ago
Are there any decent languages that compile to readable Java? I think such a language would have a place in conservative Java shops, where management insists "we only use plain old Java around here". You could program in a "cleaner Java" translate it to vanilla Java, then commit, and nobody would know the difference.
- throwaway13337 10y ago
  Xtend from the eclipse foundation does just that - it compiles to plain java, not bytecode. http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/ Kotlin follows a very similar path as it does, but to greater success. I played with xtend a few years ago and now I use kotlin for my jvm tasks.
- snaky 10y ago
  > Linj is a Common Lisp-like language that tries to be as similar to Common Lisp as possible but allowing Linj programs to be compiled into human-readable Java code https://github.com/xach/linj https://github.com/xach/linj
- tigershark 10y ago
  If you ever tried to push some Java-generated code in the repository I will never ever approve your pull request. It's simply one of the most wrong thing that you can do on so many levels that I really don't know from where to start. You will need to keep track separately of the kotlin code and Java code and keep them in synch. You cannot use the repository because, per your admission, you are doing this in secret, so if your machine dies then you lose all the original kotlin code. Even if you didn't lose the original kotlin source future iterations of the language may change the generated code, so even if you simply remove a comment your pull request will have changes in pretty much all the generated files. A simple refactoring can have similar effects. Generated Java code in my experience can be spotted immediately given that usually is very verbose. I simply can't imagine what huge amount of code that thing will generate for a simple one liner using streams, given that it's targeting Java 6. Probably there are many more other reasons that I cannot think of early in the morning. Last but not least, I'd rather never work with someone that tries to deceive all his colleagues and pushes in the repository awful code. If you don't want to use Java then find another job, nobody is forcing you to work there.
hiyou102 10y ago
I see the biggest market for Kotlin being Android. It manages to provide features that Java will likely never have while still having a fairly small impact on run time, deploy, and APK size. The conversion tool is really great too. It makes it much easier to migrate a project to kotlin, especially when trying to figure out more complex stuff like annotations. I see Kotlin being Android's Swift in the future.
- on_and_off 10y ago
  I would love to see that happen (or something similar, like Swift). I fear that it will be hard to move in that direction as long as Google does not push in that direction though. The official word is that we don't need their support in order to write Android apps in Kotlin, which is true and that the gap between objC and Swift was large enough to justify the change but that Java is not that old, which is debatable. In all cases, it is hard to argument the move to a new language in an existing codebase when there is no official push in that direction. If I have to create a new app in the near future, I will strongly consider Kotlin, but for the 8 eight old codebase I have to deal with + the 15 engineers working on it, my hands are tied.
  - izacus 10y ago
    > In all cases, it is hard to argument the move to a new language in an existing codebase when there is no official push in that direction. I don't understand the logic behind this sentence? Why do you need Google to push you somewhere instead of you youself choosing a more productive option? Kotlin is designed to be easy to integrate into existing Java codebase and our introduction to a largeish Android codebase has been a great success.
    - on_and_off 10y ago
      For a personal project or for creating a new app from scratch where I am lead engineer, sure Kotlin would be an easy choice. However, right now I am a senior engineer working on a 8 years old android app alongside 15 other Android devs. The switch to another language is not even something that the current lead or the CTO are willing to consider. In their defense, we would have to train the whole team, this would be a major task and build times are already a big issue so anything degrading them is hard to push for. A push from Google would help a lot, it would remove a lot of objections like "this is hipster shit" or "I am not going to learn the language of the month" (coming from people who have not learned any language in years) and force them to take it seriously. Even the iOS team barely use Swift though, so I don't see it in a near future. I guess I just have to search for another company. > our introduction to a largeish Android codebase has been a great success. Do you mind sharing some details ?
Ericson2314 10y ago
> Kotlin comes from industry, not academia. It solves problems faced by working programmers today. As an example, the type system helps you avoid null pointer exceptions. I'm sorry but you just undercut your own anti-intellectualism better than I could right there. (There exist languages which have guarded against this without loss of expressive power since before Java and, oh, are from academia.)
- ansgri 10y ago
  A better example of 'engineering not academy' would be explicit vectorization, memory layout support and a good FFI. (all the stuff that in theory is better managed by compilers, in practice it either doesn't matter at all or else should be left to humans). Please correct me if I'm wrong, but Kotlin doesn't improve on Java in these areas.
  - misja111 10y ago
    It would be awesome if there would be some JVM language that supported explicit vectorization, memory layout support and a good FFI. But it also seems impossible. How would any JVM language have memory layout support while at the same time running in the memory managed sandbox of the JVM?
    - aardvark179 10y ago
      Well, project Panama is aiming to add those things to the JVM, so you may get your wish in a few years.
  - premium-concern 10y ago
    Have a look at Scala Native. Despite its young age it creates really fast, tight code (they have issues benchmarking things because Dotty Linker + LLVM gets rid of too much stuff).
    - ansgri 10y ago
      Thanks. It is too early to say if it would be of any use, however, since they don't talk about freeing these native data structures.
ternaryoperator 10y ago
>Kotlin costs nothing to adopt! It’s open source, but that’s not what I mean here. What I mean is there’s a high quality, one-click Java to Kotlin converter tool, and a strong focus on Java binary compatibility. The costs of adopting a new language are greatly more significant than implied here. The time it takes to learn it. The time it turns to learn the tools that are specific to it. And if you put it into production, the technical debt you've created by adding another language to the codebase, etc. If the OP had said that you don't have to start a green-field project to use it, that would be more accurate.
- mike_hearn 10y ago
  My experience has been that the learning curve for Kotlin is extremely shallow if you're an experienced Java developer. This is not just my experience but also the experience of building a team that's working with Kotlin all day. One reason the cost is low, is that there aren't really many tools specific to Kotlin (or any, really). You can use the same IDEs, the same build toolchains, the same libraries, even the same standard library as regular Java.
  - eropple 10y ago
    Upvoted you, but adding on: a competent Java developer can pick up Kotlin in, literally, three hours. The mappings to Java concepts are trivial, but the language's niceties quickly bear themselves out as you go.
Waterluvian 10y ago
How important is a name for uptake? I think this one might actually have an impact. Not sure why. It just looks and sounds weird. I would love to learn more about languages and marketing. Off to Google!
amaks 10y ago
What happened to Scala? Wasn't that the #1 language for JVM?
- lmm 10y ago
  Scala is still there, still growing, and a much better language. Kotlin is founded on this anti-intellectual rejection of Scala's advanced features... only to then add them back in piecemeal. So rather than a single powerful general feature like implicits or higher-kinded types you have language-level special cases like extension methods and specific nullness operators. (Don't get me wrong, there are plenty of things Scala would do differently if it were made today - there's space for a language like Ceylon that makes a genuine effort to simplify on what's in Scala)
  - seanmcdirmid 10y ago
    Anti-intellectual? More like complexity, let's be honest about motives here: it isn't "we hate types" it is "I have no idea what is going on here anymore." The "start over again and try do it right this time" is quite pervasive in PL, and even if it keeps on leading to the same problem, the motivation is always well meaning.
    - lmm 10y ago
      The line about "Kotlin comes from industry, not academia. It solves problems faced by working programmers today." is pretty naked anti-intellectualism IMO.
      - seanmcdirmid 10y ago
        You have a lower standard for anti-intellectualism than I do, I guess. From wiki: > Anti-intellectualism is hostility towards and mistrust of intellect, intellectuals, and intellectual pursuits, usually expressed as the derision of education, philosophy, literature, art, and science, as impractical and contemptible. ... In public discourse, anti-intellectuals are usually perceived and publicly present themselves as champions of the common folk—populists against political elitism and academic elitism—proposing that the educated are a social class detached from the everyday concerns of the majority, and that they dominate political discourse and higher education. The above sentence fails that test, it merely states its roots and goals can be different from academic pursuits. And it is mostly correct: at best academic work is focused on tomorrow, not today..and at worst it is focused on today but should be focused on tomorrow.
voddan 10y ago
A few people mentioned problems with Kotlin documentation (presumably with a connection to the Surprise Language round of Codeforces). Could you describe in detail the problems you had? What was unclear or misleading? Were those problems with the JVM setup or Kotlin itself?
PascalW 10y ago
When I tried Kotlin some time ago on a side project I wasn't very impressed. To me the problems Kotlin is addressing are not that huge. It feels like having to switch to another language (albeit very similar to Java) just to fix some annoyances is just not worth it. Maybe prior to Java 8 this would've been more interesting. I also wonder how much time it will take Kotlin to start benefiting from Java 9 features when that gets released.
- jmfayard 10y ago
  Keep in mind that "Prior to java 8" is a time that belongs to the distant future for the android world
ScottBurson 10y ago
Hmm, this does seem like a pretty tasteful design in many ways. The declaration-site variance for generics is a pretty good idea, but is still inadequate to deal with functional collections. (I use the term "functional" as opposed to simply "immutable": an immutable collection has no update operations at all, while a functional collection has functional update operations: for example, given a set S and an element X, to compute a new set whose elements are those of S together with X (S ∪ {X}). This usage is certainly not universal, but the distinction needs to be drawn somehow.) Anyway, the point is this. Kotlin has in its collections API interface Set<out E> ... where the use of 'out' says that given types A and B where B is a subtype of A, 'Set<B>' is a subtype of 'Set<A>'. But then if you wanted to add a 'with' operation as described above: interface FunctionalSet<out E> : Set<E> { fun with(E elt) } you can't do it, because type parameters marked with 'out' can't be used for method parameters.
- lmm 10y ago
  The correct signature for that method is something like (don't know whether this is the syntax) fun with<F super E>(F elt)
  - ScottBurson 10y ago
    I guess you mean (note the return type) fun with<F super E>(elt: F): FunctionalSet<F> That's an interesting suggestion, but I don't see any indication that Kotlin provides for type lower bounds in generic function constraints. (It does have type upper bounds; see the bottom of this page: http://kotlinlang.org/docs/reference/generics.html http://kotlinlang.org/docs/reference/generics.html).
- deleted 10y ago
  [deleted]
_Codemonkeyism 10y ago
I've switched from Scala to Kotlin after 8y of Scala. There are some things I miss (e.g. Options and Futures) but Kotlin feels much more focused on real world problems. And Gradle is so much easier than the monster that is SBT.
- vorg 10y ago
  Gradle 3.0, due out soon, will provide Kotlin as an alternative language for writing build scripts, so you'll be able to use a single language for development, as you did when you used Scala with SBT.
- eropple 10y ago
  > And Gradle is so much easier than the monster that is SBT. Totally is, but I've had better luck using Maven than Gradle. Having multiple mutually compatible options is great.
vbezhenar 10y ago
For me Kotlin is almost a perfect replacement for Java. It has very few drawbacks, but generally it's much better and it's a pleasure to use it. Not to mention solid IDE support. I've used Kotlin in two small projects. One project was completed year ago and now I'm improving it. Kotlin is just awesome when it comes to refactoring or generalising. Much better than Java. I don't want to compare it to Scala, they target different auditories, IMO. I tried Scala, it's a lovely language, but it's too complex. I had to spend a month before I was able to write a quality code using Scala and I still had a lot of problems reading scala collections source code or even understand scalaz. On the other side I spent one evening reading about Kotlin (awesome and very complete, yet small documentation definitely helps) and I knew the language, could read its standard library and write production-quality code. For me that's a deal breaker.
- kailuowang 10y ago
  Yes scala is complex, but your scala code doesnt have to be. The reason that std collection lib and scalaz code is hard to read is their inclination to push the limit of utilizing the advanced scala features to make their usage really easy. That being said scala is not for one who wants to plateau quickly. It takes years.
on_and_off 10y ago
Kotlin is unquestionably a very large improvement over plain old Java. I fear it might be very hard to make the Android community adopt it massively though, unless Google pitches in and supports it officially.
- kmiroslav 10y ago
  The Android community has already adopted it pretty significantly (join the #android Kotlin slack and see for yourself). And this was done without any official support for Google because... it's not necessary: Kotlin works out of the box. Which is one of Kotlin's strengths.
  - on_and_off 10y ago
    I am in that slack channel. Do you have any adoption numbers though ? From what I see in the local companies, kotlin is still very rare, except for a couple of startups (which makes them very attractive tbh). That anecdotal evidence of course and I would love to see a tide change but hard numbers would be an huge help.
  - watchxxx 10y ago
    http://www.indeed.com/jobtrends/q-android-q-kotlin.html http://www.indeed.com/jobtrends/q-android-q-kotlin.html
bbcbasic 10y ago
It's the least sexy name for a programming language this century
- scrame 10y ago
  Groovy won that 10 years ago.
  - vorg 10y ago
    Groovy was named by its creator, James Strachan, in 2003. By 2006 (i.e. 10 years ago), he had been managed out and a business sort without technical knowledge had taken over. He's since slowly wrecked Groovy's sexy brand and placed it firmly in the Java camp. I tried reversing the trend with stuff like "grOOvy", and the Groovy grrrrrrowl, Ooooooooo, and Vy (for "victory") but that business person running Groovy skuttled the effort, appearing far more interested in retaining his centralized control over Groovy branding. Groovy's since been handed over to Apache, being run by a 10-member "Project Management Committee", only 4 of which actually do any technical work on Groovy's code base. The other 6, including the "PMC Chair", just do administrative fuss.
korm 10y ago
With the exception of compiling to JVM, Dart is worth looking at if you liked this. Most of the article applies to it as well: https://www.dartlang.org/docs/dart-up-and-running/ch02.html https://www.dartlang.org/docs/dart-up-and-running/ch02.html With dart news in the past 4 years, the knee-jerk reaction has been that Google will abandon it, which unfortunately means that not much discussion ever went to its merits. Adopting the language has provided a huge productivity boost for me and many other developers, in or outside Google.
thirdreplicator 10y ago
Features: ========= * compiles to Java and Javascript * null safety (optionality) * Lean syntax * Exceptions are unchecked. * Extension functions let you add methods to classes without modifying their source code. * Operator overloading * No macros * Markdown instead of HTML for your API docs * Better Java generics. * Delegation (forwarding methods) * String interpolation Seriously underwhelming....
- amelius 10y ago
  It seems like a very pragmatic language, aimed at anything above "systems programming" and not suitable for high-performance (scientific) programming. Not many theoretical advancements in programming language design, if any. Too much of a hodge-podge of features. I would say this language may become interesting only if it gets enough traction from a community.
- jsmith0295 10y ago
  I initially used Kotlin for a project at work, and I would agree that it is underwhelming. Pivotal had announced official support for Kotlin with Spring Boot, which is what motivated me to give it a try. However, there was no support for the @Transactional annotation in Kotlin at the time, so I ended up writing a decent amount of Java anyways. Then there was a compatibility issue with one of our internal libraries, and I had to rewrite all of the controllers in Java. By the time the project was finished, the majority of the code was in Java, and I hadn't really gotten any benefit out of the Kotlin, so I decided to just use Lombok and replace all of the Kotlin code with Java. My builds got about 3 times faster after that because Kotlin seems to have performance issues with Gradle. The 1.1 release is promising many features that make me want to revisit it, though: https://blog.jetbrains.com/kotlin/2016/04/kotlin-post-1-0-roadmap/ https://blog.jetbrains.com/kotlin/2016/04/kotlin-post-1-0-ro...
  - vbezhenar 10y ago
    As of 1.0 Kotlin has solid Java compatibility, @Transactional definitely shouldn't be an issue. What features are compelling for you in 1.1? They are nice, but generally just a nice sugar. I don't really miss any of those. I suggest you to try it now, if you have a chance.
marvel_boy 10y ago
We're in 2016 and Swift is the new rage. In no time it will be the new multiplatform mobile default option.
- yomism 10y ago
  Android I don't think so... There are tons of Java code in the Android ecosystem and their developers hate anything that comes from Apple. So it will end as iOS only.
eggy 10y ago
I know they don't have the 'production-ready' stamp, but if I were to jump back into the JVM world it would be Frege at this point. It is basically a Haskell on the JVM. It compiles to Java source code, so you can work it in slowly to your real project [1]. You can call Java from Frege, or Frege functions from Java. ABCL - Armed Bear Common Lisp is another, but Lisp on the JVM instead of Haskell. It's been around for a while, and has become fast for a Lisp on the JVM, though it's not SBCL in speed. It does however support full 32 bit integers on 32 bits sytems compared with SBCL's 29 bits on 32 bit systems due to boxing. Again, not used much in production, although, there are some great testimonials of some cool implementations [2]. I particularly like the Keck telescope code written in Lisp in 1994, ported to ABCL and using Java for some image work and display. [1] https://github.com/frege/frege https://github.com/frege/frege [2] https://common-lisp.net/project/armedbear/testimonials.shtml https://common-lisp.net/project/armedbear/testimonials.shtml
izacus 10y ago
Wow, so much negativity here O.o Kotlin is getting rapid adoption in the Android community and is quickly getting the same status as Swift has in the iOS world. The main reasons for the rapid adoption are: - It's designed to easily integrate into existing Java codebases. This means that starting to use Kotlin is pretty much a case of adding two Gradle dependencies and source files into `src/kotlin`. Interop with Java is painless and doesn't require any special boxing as opposed to some other languages. - It's standard library is small (~700KB), which is a stark contrast to Scala and some other JVM languages, which pretty much demand usage of ProGuard while developing due to large method count. - It's performance characteristics are close to Java and doesn't cause catastrophic GC collection issues like some Clojure code does. - It has pretty much all the features expected from a modern language (nullability, const values, concise syntax) while still keeping code very readable for people who already know Java. The adoption in our Java codebase has thus been rather painless, since code doesn't do any additional magic you wouldn't expect. - It compiles code to Java bytecode which runs on Java 6 JVM, which is critical for Android. - It has first-party support in IntelliJ IDEs, which includes Android Studio itself. The IDE experience is significantly better than Scala or Clojure one and almost on par with Java. So in short, we got a modern language, which is easy to transition to from Java 6, gives seamless interoperability with existing Java code (you can just start writing Kotlin classes in your Java code base), doesn't add overhead to your Android application and doesn't behave strangely performance-wise. There are still some warts to fix (mostly related to static checkers), but Kotlin has been a huge win for Android world.
- Razengan 10y ago
  > quickly getting the same status as Swift has in the iOS world. What's keeping Swift itself from eventually becoming the preferred language for Android as well?
  - izacus 10y ago
    The fact that it would have to talk to Android via JNI bridge like C/C++/Go and other languages that don't compile to JVM. And the fact that there's no standard library outside the Apple world for the language. Adoption of Swift makes pretty much no sense, technologically or politically.
sgarman 10y ago
The author talks a bit about how he ended up back in JVM world when they started on Android dev. I just want to note that Android does not use the JVM but Dalvik (I think it's actually called ART now). Maybe they just meant Android put them back in the world of Java.

133 points by insulanian 10y ago

I tried Kotlin during the Surprise Language round of Codeforces, a programming competition. I found it to be more verbose than a typical modern scripting language. Maybe it's the result of choosing the least of the evils for what it's trying to accomplish. The other drawback: the documentation. Kotlin's reference documentation (looking up how to properly use a call) does not have any examples. I'm not even talking about full compilable examples - although that would be nice, it doesn't even have one-liner examples. FWIW, I was trying to look up how to use a comparator to sort a MutableArray<Int,Int>.

rattray 10y ago
Personally I don't much mind the added verbosity, coming from Ruby/Python/JS, so long as I don't have to write so many damn tests. Speaking from minimal experience, Kotlin still seems like a big net win here. Same is true of other languages with lightweight, static type systems like TypeScript/Flow, Swift, and Go. I agree about the documentation – I think it's one of the biggest reasons the language has seen such little adoption given its benefits. I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. Kotlin is developed by Jetbrains, so of course they're used to IDE-driven-development, and have a financial stake in people using their products for development. But coming from scripting languages, this sort of documentation gap was a real turn-off for me.
- Bromskloss 10y ago
  What is it that makes you not having to write so many tests?
  - smt88 10y ago
    A decent type system
  - iends 10y ago
    Static typing.
    - Bromskloss 10y ago
      Is the reasoning that you then don't have to test what happens if you pass a parameter of the wrong type to a function?
      - bbcbasic 10y ago
        The compiler guarantees it won't happen. Such a test would be a test of the compiler and in my opinion unnecessary. And in Haskell at least... impossible. You can't write the the test because IT won't compile!
        Bromskloss 10y ago
        I understand that. My question is if that is the kind of tests that people have in mind when they say that static typing requires fewer tests.
        bbcbasic 10y ago
        I can't speak for anyone else but I believe so yes.
        iends 10y ago
        Yes. When writing JS you have to explicitly do a lot more validation.
  - StavrosK 10y ago
    Without looking, I'm guessing static typing.
- eropple 10y ago
  > I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. I would suggest (and I'm not trying to bag on you with this) that this concern is more your unfamiliarity with the JVM than a failure of Kotlin, which is generally targeting Java and Scala developers. Kotlin operates pretty idiomatically in the Java universe and, as an experienced JVM developer who's comfortable with all of Maven, Gradle, and SBT, I dropped Kotlin into a Maven project, side-by-side with Java, with a cursory glance at the documentation--"oh, it's another pre-compile-step thing". (Which I then consume via IntelliJ, because IntelliJ imports Maven projects nicely, but Maven allows others to use their IDE of choice.) The pre-compile-step thing sucks, I'll be the first to say that, and it's a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably. I prefer to use multi-module Maven projects and separate out Java and Kotlin--or Scala, for that matter--code into separate ones. But that's a different beast entirely from the initial bootstrap when learning.
  - rattray 10y ago
    > your unfamiliarity with the JVM Correct! > a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably A bummer to hear – though I'm glad it's not just me. I tried using Kotlin with the Play Framework and did not have a great time. The hot-reloading features of Play didn't work with Kotlin at all, even with my attempts to `touch` a Java file whenever my Kotlin file changed (presumably they're recompiling more intelligently than I was). Perhaps having SomeController.java and SomeController.kt in parallel, where the former imports the latter, and receives a `touch` or similar whenever the Kotlin file changes, might work? Or would you recon such a project to be a fool's errand?
    - eropple 10y ago
      Play isn't built for Kotlin and SBT is kind of a tire fire in general. I would suggest something more like Dropwizard for use with non-Scala JVM languages.
      - EtienneK 10y ago
- meddlepal 10y ago
  I agree the documentation needs work and I am using Kotlin in prod. JetBrains please take note!
  - voddan 10y ago
    Could you please elaborate on what needs improving in the docs? Btw, the whole kotlinlang.org is OSS, and you can correct things you don't
- winstonewert 10y ago
  What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.
  - sanderjd 10y ago
    Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.
    - dmichulke 10y ago
      I address this problem by checking the type at run-time via an assertion. Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production. Writing specific tests for that looks very inefficient to me but maybe I am missing something.
      - bbcbasic 10y ago
        I don't see how this reduces the need for a test that the wrong type is handled correctly.
        dmichulke 10y ago
        The underlying idea is that it shouldn't handle the wrong type at all, it should fail. If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.
        mac01021 10y ago
        And you don't need tests to make sure the assertions are there?
- cageface 10y ago
  Absolutely. Dynamic languages only seem terse because you don't see all the associated test code inline. I've been programming in a mix of dynamic and statically typed languages for more than 15 years now and I'll take a modern statically typed language over a dynamic language any time if I have my choice. It's a lot harder to design a static type system that's both expressive enough to be pleasant to use and strict enough to be useful. But we're getting there in modern languages like Rust, Kotlin, Swift etc.
- voddan 10y ago
  "integrate Kotlin files into a Java project without using IntelliJ" - compilation of a mixed project is not a trivial tasks, many things must be set up. A detailed description of this takes a chapter in a book. That's the reason one should use build tools, be it Ant, Maven, or Gradle. The process of setting them up without an IDE is narrowly described in the docs https://kotlinlang.org/docs/tutorials/build-tools.html https://kotlinlang.org/docs/tutorials/build-tools.html
fierycatnet 10y ago
From what I understand Kotlin is the language that was designed to be used in house by JetBrains to simplify their Java code. It wasn't born to be the revolutionary, just practical for Java developers.
voddan 10y ago
The Kotlin reference is not supposed to be used for finding methods. The way to go is to use auto completion in an IDE. If you type `myArray.sort<ctrl+space>`, you get all one needs, including `sort`, `sorted`, `sortBy` (which you needed). Alternatively you could search the reference page for Array or MutableList or MutableMap, not sure what you wanted: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-mutable-list/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collecti... https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-mutable-map/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collecti...
- Scene_Cast2 10y ago
  I had something like this: var heights: Array< Pair<Int, Int> > = ... //populating the array heights.sortBy { it.second }; It was not obvious at all that I had to use curly braces. The documentation says: inline fun <T, R : Comparable<R>> MutableList<T>.sortBy( crossinline selector: (T) -> R?) (source) This is after I figured out that I'm not supposed to use sortWith (I never figured out how to use this one)
  - voddan 10y ago
    The curly braces are the syntax for lambdas, one of the basic types `(T) -> R?`. There are plenty of examples for using that, but in the respective chapters: https://kotlinlang.org/docs/reference/lambdas.html#higher-order-functions https://kotlinlang.org/docs/reference/lambdas.html#higher-or... or in this bunch of examples: https://kotlinlang.org/docs/reference/idioms.html#filtering-a-list https://kotlinlang.org/docs/reference/idioms.html#filtering-... The docs are arranged in a way that one reads them in the order they are written (at least the first half). I supposed that would take more than half an hour given at the competition. I don't think Kotlin is the best choice for programming challenges like codeforces - they really don't let him shine (although I use it whenever I can). But if this is a valid case, we can collaborate and write a short tutorial for C/C++ to Kotlin programmers.
  - Scene_Cast2 10y ago
n72 10y ago
For those who want docs in the examples, perhaps "liking" my post regarding this on the kotlin discussion forum would help: https://discuss.kotlinlang.org/t/examples-in-the-api-docs/1646 https://discuss.kotlinlang.org/t/examples-in-the-api-docs/16...

komone 10y ago

Yeah. No.

ld00d 10y ago

I really liked Scala when I played around with it (bare with me here), but when deciding on what to use on a project I'm starting, targeting the JVM is a downside. Can I depend on the JVM being on the target machine? If not, I'll have to deal with the dependency. However, if I choose a compiled language like Rust, I don't have to worry about that.

smt88 10y ago
Most people writing Java will be able to control the presence of the JVM. Only B2C desktop apps, which are fairly rare these days, will have to worry much about the dependency.
- ld00d 10y ago
  Unless you're doing JavaFX or something like that.
eropple 10y ago
Under what circumstances are you writing software for deployment in places you don't have administration access on (i.e., your servers, which should be deployed with CM as-is and make adding dependencies trivial) where you cannot package OpenJDK (this is trivial on Windows, OS X, and Linux), cannot expect a system administrator to install the JVM, and can expect Rust to run? There is a slice of the universe where this exists, but it's not really Kotlin's target in the first place (and I think that's basically self-evident from everything around it) so I'm not sure why you'd try to jam that square peg in the round hole to begin with.
- ld00d 10y ago
  I'm thinking of client machines. People balk at installing Java these days. Is there a way to get the JVM without Java? Is Kotlin not capable of being a client application?
  - tormeh 10y ago
    You just package the JVM with the application itself. Create a .bat/.exe/.sh/binary file that calls the JVM with your program as the argument. It's simple, but it will increase the download size of your program significantly (unless your program is huge - then it doesn't matter)

kmiroslav 10y ago

Should probably be renamed "Why Kotlin is my current programming language".

hnxx 10y ago

Kotlin reminds me of coffescript to JavaScript.

highwind 10y ago
As far as I know, all CoffeeScript did was add bunch of syntactic sugar on top of JavaScript. I believe Kotlin actually adds programming paradigm that's not in Java on top of terse syntax, i.e. real closure, operator overloading, pure object orientation, and more.
- lmm 10y ago
  Java already has real closures and pure object orientation. Operator overloading is just sugar.
ungzd 10y ago
And also may become obsolete after Java 8/9 (as Coffeescript after ES6/7). Problem is that noone in Java body shops ever touched Java 8, they're still migrating from Java 5 to Java 6.

charlieflowers 10y ago

I am a bit in a hurry, so I acknowledge I only quickly scanned the article. But it struck me as damning by faint praise. Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." No offense intended ... that's just my quick take.

deleted 10y ago
[deleted]
jkot 10y ago
> If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." I think that is wrong approach. Kotlin has nothing special or innovative, everything was already here. But it is well balanced and industrial strength (something like java). It is simply good workhorse for most tasks. It is excellent replacement for java, that is all.
- reality_czech 10y ago
  Now that JDK8 has made Java more expressive, and Oracle's trolling has come to nothing, I expect Kotlin and Ceylon to fade away. If you want Java, just use it, already.
  - Nullabillity 10y ago
    Java 8 improved things, but it's still far behind the rest. Also, both Kotlin and Ceylon (and Scala and Clojure) would be affected by the Oracle trolling, since they all run on the JVM.
KaneMorgan 10y ago
I actually like that it's informational rather than ideological.

Buttons840 10y ago

Are there any decent languages that compile to readable Java? I think such a language would have a place in conservative Java shops, where management insists "we only use plain old Java around here". You could program in a "cleaner Java" translate it to vanilla Java, then commit, and nobody would know the difference.

throwaway13337 10y ago
Xtend from the eclipse foundation does just that - it compiles to plain java, not bytecode. http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/ Kotlin follows a very similar path as it does, but to greater success. I played with xtend a few years ago and now I use kotlin for my jvm tasks.
snaky 10y ago
> Linj is a Common Lisp-like language that tries to be as similar to Common Lisp as possible but allowing Linj programs to be compiled into human-readable Java code https://github.com/xach/linj https://github.com/xach/linj
tigershark 10y ago
If you ever tried to push some Java-generated code in the repository I will never ever approve your pull request. It's simply one of the most wrong thing that you can do on so many levels that I really don't know from where to start. You will need to keep track separately of the kotlin code and Java code and keep them in synch. You cannot use the repository because, per your admission, you are doing this in secret, so if your machine dies then you lose all the original kotlin code. Even if you didn't lose the original kotlin source future iterations of the language may change the generated code, so even if you simply remove a comment your pull request will have changes in pretty much all the generated files. A simple refactoring can have similar effects. Generated Java code in my experience can be spotted immediately given that usually is very verbose. I simply can't imagine what huge amount of code that thing will generate for a simple one liner using streams, given that it's targeting Java 6. Probably there are many more other reasons that I cannot think of early in the morning. Last but not least, I'd rather never work with someone that tries to deceive all his colleagues and pushes in the repository awful code. If you don't want to use Java then find another job, nobody is forcing you to work there.

hiyou102 10y ago

I see the biggest market for Kotlin being Android. It manages to provide features that Java will likely never have while still having a fairly small impact on run time, deploy, and APK size. The conversion tool is really great too. It makes it much easier to migrate a project to kotlin, especially when trying to figure out more complex stuff like annotations. I see Kotlin being Android's Swift in the future.

on_and_off 10y ago
I would love to see that happen (or something similar, like Swift). I fear that it will be hard to move in that direction as long as Google does not push in that direction though. The official word is that we don't need their support in order to write Android apps in Kotlin, which is true and that the gap between objC and Swift was large enough to justify the change but that Java is not that old, which is debatable. In all cases, it is hard to argument the move to a new language in an existing codebase when there is no official push in that direction. If I have to create a new app in the near future, I will strongly consider Kotlin, but for the 8 eight old codebase I have to deal with + the 15 engineers working on it, my hands are tied.
- izacus 10y ago
  > In all cases, it is hard to argument the move to a new language in an existing codebase when there is no official push in that direction. I don't understand the logic behind this sentence? Why do you need Google to push you somewhere instead of you youself choosing a more productive option? Kotlin is designed to be easy to integrate into existing Java codebase and our introduction to a largeish Android codebase has been a great success.
  - on_and_off 10y ago
    For a personal project or for creating a new app from scratch where I am lead engineer, sure Kotlin would be an easy choice. However, right now I am a senior engineer working on a 8 years old android app alongside 15 other Android devs. The switch to another language is not even something that the current lead or the CTO are willing to consider. In their defense, we would have to train the whole team, this would be a major task and build times are already a big issue so anything degrading them is hard to push for. A push from Google would help a lot, it would remove a lot of objections like "this is hipster shit" or "I am not going to learn the language of the month" (coming from people who have not learned any language in years) and force them to take it seriously. Even the iOS team barely use Swift though, so I don't see it in a near future. I guess I just have to search for another company. > our introduction to a largeish Android codebase has been a great success. Do you mind sharing some details ?

Ericson2314 10y ago

> Kotlin comes from industry, not academia. It solves problems faced by working programmers today. As an example, the type system helps you avoid null pointer exceptions. I'm sorry but you just undercut your own anti-intellectualism better than I could right there. (There exist languages which have guarded against this without loss of expressive power since before Java and, oh, are from academia.)

ansgri 10y ago
A better example of 'engineering not academy' would be explicit vectorization, memory layout support and a good FFI. (all the stuff that in theory is better managed by compilers, in practice it either doesn't matter at all or else should be left to humans). Please correct me if I'm wrong, but Kotlin doesn't improve on Java in these areas.
- misja111 10y ago
  It would be awesome if there would be some JVM language that supported explicit vectorization, memory layout support and a good FFI. But it also seems impossible. How would any JVM language have memory layout support while at the same time running in the memory managed sandbox of the JVM?
  - aardvark179 10y ago
    Well, project Panama is aiming to add those things to the JVM, so you may get your wish in a few years.
- premium-concern 10y ago
  Have a look at Scala Native. Despite its young age it creates really fast, tight code (they have issues benchmarking things because Dotty Linker + LLVM gets rid of too much stuff).
  - ansgri 10y ago
    Thanks. It is too early to say if it would be of any use, however, since they don't talk about freeing these native data structures.

ternaryoperator 10y ago

>Kotlin costs nothing to adopt! It’s open source, but that’s not what I mean here. What I mean is there’s a high quality, one-click Java to Kotlin converter tool, and a strong focus on Java binary compatibility. The costs of adopting a new language are greatly more significant than implied here. The time it takes to learn it. The time it turns to learn the tools that are specific to it. And if you put it into production, the technical debt you've created by adding another language to the codebase, etc. If the OP had said that you don't have to start a green-field project to use it, that would be more accurate.

mike_hearn 10y ago
My experience has been that the learning curve for Kotlin is extremely shallow if you're an experienced Java developer. This is not just my experience but also the experience of building a team that's working with Kotlin all day. One reason the cost is low, is that there aren't really many tools specific to Kotlin (or any, really). You can use the same IDEs, the same build toolchains, the same libraries, even the same standard library as regular Java.
- eropple 10y ago
  Upvoted you, but adding on: a competent Java developer can pick up Kotlin in, literally, three hours. The mappings to Java concepts are trivial, but the language's niceties quickly bear themselves out as you go.

Waterluvian 10y ago

How important is a name for uptake? I think this one might actually have an impact. Not sure why. It just looks and sounds weird. I would love to learn more about languages and marketing. Off to Google!

amaks 10y ago

What happened to Scala? Wasn't that the #1 language for JVM?

lmm 10y ago
Scala is still there, still growing, and a much better language. Kotlin is founded on this anti-intellectual rejection of Scala's advanced features... only to then add them back in piecemeal. So rather than a single powerful general feature like implicits or higher-kinded types you have language-level special cases like extension methods and specific nullness operators. (Don't get me wrong, there are plenty of things Scala would do differently if it were made today - there's space for a language like Ceylon that makes a genuine effort to simplify on what's in Scala)
- seanmcdirmid 10y ago
  Anti-intellectual? More like complexity, let's be honest about motives here: it isn't "we hate types" it is "I have no idea what is going on here anymore." The "start over again and try do it right this time" is quite pervasive in PL, and even if it keeps on leading to the same problem, the motivation is always well meaning.
  - lmm 10y ago
    The line about "Kotlin comes from industry, not academia. It solves problems faced by working programmers today." is pretty naked anti-intellectualism IMO.
    - seanmcdirmid 10y ago
      You have a lower standard for anti-intellectualism than I do, I guess. From wiki: > Anti-intellectualism is hostility towards and mistrust of intellect, intellectuals, and intellectual pursuits, usually expressed as the derision of education, philosophy, literature, art, and science, as impractical and contemptible. ... In public discourse, anti-intellectuals are usually perceived and publicly present themselves as champions of the common folk—populists against political elitism and academic elitism—proposing that the educated are a social class detached from the everyday concerns of the majority, and that they dominate political discourse and higher education. The above sentence fails that test, it merely states its roots and goals can be different from academic pursuits. And it is mostly correct: at best academic work is focused on tomorrow, not today..and at worst it is focused on today but should be focused on tomorrow.

voddan 10y ago

A few people mentioned problems with Kotlin documentation (presumably with a connection to the Surprise Language round of Codeforces). Could you describe in detail the problems you had? What was unclear or misleading? Were those problems with the JVM setup or Kotlin itself?

PascalW 10y ago

When I tried Kotlin some time ago on a side project I wasn't very impressed. To me the problems Kotlin is addressing are not that huge. It feels like having to switch to another language (albeit very similar to Java) just to fix some annoyances is just not worth it. Maybe prior to Java 8 this would've been more interesting. I also wonder how much time it will take Kotlin to start benefiting from Java 9 features when that gets released.

jmfayard 10y ago
Keep in mind that "Prior to java 8" is a time that belongs to the distant future for the android world

ScottBurson 10y ago

Hmm, this does seem like a pretty tasteful design in many ways. The declaration-site variance for generics is a pretty good idea, but is still inadequate to deal with functional collections. (I use the term "functional" as opposed to simply "immutable": an immutable collection has no update operations at all, while a functional collection has functional update operations: for example, given a set S and an element X, to compute a new set whose elements are those of S together with X (S ∪ {X}). This usage is certainly not universal, but the distinction needs to be drawn somehow.) Anyway, the point is this. Kotlin has in its collections API interface Set<out E> ... where the use of 'out' says that given types A and B where B is a subtype of A, 'Set<B>' is a subtype of 'Set<A>'. But then if you wanted to add a 'with' operation as described above: interface FunctionalSet<out E> : Set<E> { fun with(E elt) } you can't do it, because type parameters marked with 'out' can't be used for method parameters.

lmm 10y ago
The correct signature for that method is something like (don't know whether this is the syntax) fun with<F super E>(F elt)
- ScottBurson 10y ago
  I guess you mean (note the return type) fun with<F super E>(elt: F): FunctionalSet<F> That's an interesting suggestion, but I don't see any indication that Kotlin provides for type lower bounds in generic function constraints. (It does have type upper bounds; see the bottom of this page: http://kotlinlang.org/docs/reference/generics.html http://kotlinlang.org/docs/reference/generics.html).
deleted 10y ago
[deleted]

_Codemonkeyism 10y ago

I've switched from Scala to Kotlin after 8y of Scala. There are some things I miss (e.g. Options and Futures) but Kotlin feels much more focused on real world problems. And Gradle is so much easier than the monster that is SBT.

vorg 10y ago
Gradle 3.0, due out soon, will provide Kotlin as an alternative language for writing build scripts, so you'll be able to use a single language for development, as you did when you used Scala with SBT.
eropple 10y ago
> And Gradle is so much easier than the monster that is SBT. Totally is, but I've had better luck using Maven than Gradle. Having multiple mutually compatible options is great.

vbezhenar 10y ago

For me Kotlin is almost a perfect replacement for Java. It has very few drawbacks, but generally it's much better and it's a pleasure to use it. Not to mention solid IDE support. I've used Kotlin in two small projects. One project was completed year ago and now I'm improving it. Kotlin is just awesome when it comes to refactoring or generalising. Much better than Java. I don't want to compare it to Scala, they target different auditories, IMO. I tried Scala, it's a lovely language, but it's too complex. I had to spend a month before I was able to write a quality code using Scala and I still had a lot of problems reading scala collections source code or even understand scalaz. On the other side I spent one evening reading about Kotlin (awesome and very complete, yet small documentation definitely helps) and I knew the language, could read its standard library and write production-quality code. For me that's a deal breaker.

kailuowang 10y ago
Yes scala is complex, but your scala code doesnt have to be. The reason that std collection lib and scalaz code is hard to read is their inclination to push the limit of utilizing the advanced scala features to make their usage really easy. That being said scala is not for one who wants to plateau quickly. It takes years.

on_and_off 10y ago

Kotlin is unquestionably a very large improvement over plain old Java. I fear it might be very hard to make the Android community adopt it massively though, unless Google pitches in and supports it officially.

kmiroslav 10y ago
The Android community has already adopted it pretty significantly (join the #android Kotlin slack and see for yourself). And this was done without any official support for Google because... it's not necessary: Kotlin works out of the box. Which is one of Kotlin's strengths.
- on_and_off 10y ago
  I am in that slack channel. Do you have any adoption numbers though ? From what I see in the local companies, kotlin is still very rare, except for a couple of startups (which makes them very attractive tbh). That anecdotal evidence of course and I would love to see a tide change but hard numbers would be an huge help.
- watchxxx 10y ago
  http://www.indeed.com/jobtrends/q-android-q-kotlin.html http://www.indeed.com/jobtrends/q-android-q-kotlin.html

bbcbasic 10y ago

It's the least sexy name for a programming language this century

scrame 10y ago
Groovy won that 10 years ago.
- vorg 10y ago
  Groovy was named by its creator, James Strachan, in 2003. By 2006 (i.e. 10 years ago), he had been managed out and a business sort without technical knowledge had taken over. He's since slowly wrecked Groovy's sexy brand and placed it firmly in the Java camp. I tried reversing the trend with stuff like "grOOvy", and the Groovy grrrrrrowl, Ooooooooo, and Vy (for "victory") but that business person running Groovy skuttled the effort, appearing far more interested in retaining his centralized control over Groovy branding. Groovy's since been handed over to Apache, being run by a 10-member "Project Management Committee", only 4 of which actually do any technical work on Groovy's code base. The other 6, including the "PMC Chair", just do administrative fuss.

korm 10y ago

With the exception of compiling to JVM, Dart is worth looking at if you liked this. Most of the article applies to it as well: https://www.dartlang.org/docs/dart-up-and-running/ch02.html https://www.dartlang.org/docs/dart-up-and-running/ch02.html With dart news in the past 4 years, the knee-jerk reaction has been that Google will abandon it, which unfortunately means that not much discussion ever went to its merits. Adopting the language has provided a huge productivity boost for me and many other developers, in or outside Google.

thirdreplicator 10y ago

Features: ========= * compiles to Java and Javascript * null safety (optionality) * Lean syntax * Exceptions are unchecked. * Extension functions let you add methods to classes without modifying their source code. * Operator overloading * No macros * Markdown instead of HTML for your API docs * Better Java generics. * Delegation (forwarding methods) * String interpolation Seriously underwhelming....

amelius 10y ago
It seems like a very pragmatic language, aimed at anything above "systems programming" and not suitable for high-performance (scientific) programming. Not many theoretical advancements in programming language design, if any. Too much of a hodge-podge of features. I would say this language may become interesting only if it gets enough traction from a community.
jsmith0295 10y ago
I initially used Kotlin for a project at work, and I would agree that it is underwhelming. Pivotal had announced official support for Kotlin with Spring Boot, which is what motivated me to give it a try. However, there was no support for the @Transactional annotation in Kotlin at the time, so I ended up writing a decent amount of Java anyways. Then there was a compatibility issue with one of our internal libraries, and I had to rewrite all of the controllers in Java. By the time the project was finished, the majority of the code was in Java, and I hadn't really gotten any benefit out of the Kotlin, so I decided to just use Lombok and replace all of the Kotlin code with Java. My builds got about 3 times faster after that because Kotlin seems to have performance issues with Gradle. The 1.1 release is promising many features that make me want to revisit it, though: https://blog.jetbrains.com/kotlin/2016/04/kotlin-post-1-0-roadmap/ https://blog.jetbrains.com/kotlin/2016/04/kotlin-post-1-0-ro...
- vbezhenar 10y ago
  As of 1.0 Kotlin has solid Java compatibility, @Transactional definitely shouldn't be an issue. What features are compelling for you in 1.1? They are nice, but generally just a nice sugar. I don't really miss any of those. I suggest you to try it now, if you have a chance.

marvel_boy 10y ago

We're in 2016 and Swift is the new rage. In no time it will be the new multiplatform mobile default option.

yomism 10y ago
Android I don't think so... There are tons of Java code in the Android ecosystem and their developers hate anything that comes from Apple. So it will end as iOS only.

eggy 10y ago

I know they don't have the 'production-ready' stamp, but if I were to jump back into the JVM world it would be Frege at this point. It is basically a Haskell on the JVM. It compiles to Java source code, so you can work it in slowly to your real project [1]. You can call Java from Frege, or Frege functions from Java. ABCL - Armed Bear Common Lisp is another, but Lisp on the JVM instead of Haskell. It's been around for a while, and has become fast for a Lisp on the JVM, though it's not SBCL in speed. It does however support full 32 bit integers on 32 bits sytems compared with SBCL's 29 bits on 32 bit systems due to boxing. Again, not used much in production, although, there are some great testimonials of some cool implementations [2]. I particularly like the Keck telescope code written in Lisp in 1994, ported to ABCL and using Java for some image work and display. [1] https://github.com/frege/frege https://github.com/frege/frege [2] https://common-lisp.net/project/armedbear/testimonials.shtml https://common-lisp.net/project/armedbear/testimonials.shtml

izacus 10y ago

Wow, so much negativity here O.o Kotlin is getting rapid adoption in the Android community and is quickly getting the same status as Swift has in the iOS world. The main reasons for the rapid adoption are: - It's designed to easily integrate into existing Java codebases. This means that starting to use Kotlin is pretty much a case of adding two Gradle dependencies and source files into `src/kotlin`. Interop with Java is painless and doesn't require any special boxing as opposed to some other languages. - It's standard library is small (~700KB), which is a stark contrast to Scala and some other JVM languages, which pretty much demand usage of ProGuard while developing due to large method count. - It's performance characteristics are close to Java and doesn't cause catastrophic GC collection issues like some Clojure code does. - It has pretty much all the features expected from a modern language (nullability, const values, concise syntax) while still keeping code very readable for people who already know Java. The adoption in our Java codebase has thus been rather painless, since code doesn't do any additional magic you wouldn't expect. - It compiles code to Java bytecode which runs on Java 6 JVM, which is critical for Android. - It has first-party support in IntelliJ IDEs, which includes Android Studio itself. The IDE experience is significantly better than Scala or Clojure one and almost on par with Java. So in short, we got a modern language, which is easy to transition to from Java 6, gives seamless interoperability with existing Java code (you can just start writing Kotlin classes in your Java code base), doesn't add overhead to your Android application and doesn't behave strangely performance-wise. There are still some warts to fix (mostly related to static checkers), but Kotlin has been a huge win for Android world.

Razengan 10y ago
> quickly getting the same status as Swift has in the iOS world. What's keeping Swift itself from eventually becoming the preferred language for Android as well?
- izacus 10y ago
  The fact that it would have to talk to Android via JNI bridge like C/C++/Go and other languages that don't compile to JVM. And the fact that there's no standard library outside the Apple world for the language. Adoption of Swift makes pretty much no sense, technologically or politically.

sgarman 10y ago

The author talks a bit about how he ended up back in JVM world when they started on Android dev. I just want to note that Android does not use the JVM but Dalvik (I think it's actually called ART now). Maybe they just meant Android put them back in the world of Java.