17 ms·

Ask HN: Has anyone here programmed in Kotlin? What do you think about it?

190 points by lemevi 11y ago

I was looking at Kotlin and was curious. It looks very interesting feature wise but I worry about its long term viability given it's low presence on GitHub[1] and < 40 users on #kotlin on Freenode IRC. Is this worth writing a big project in? [1] https://github.com/search?o=desc&q=language%3AKotlin&ref=searchresults&s=stars&type=Repositories&utf8=

comrade1 11y ago
Where's Kotlin?
- Joky 11y ago
  Kotlin is in the kitchen! (with Bryan)
yareally 11y ago
> I worry about its long term viability given it's low presence on GitHub[1] and < 40 users on #kotlin on Freenode IRC It's only on version 0.12.213. Bit premature to judge long term viability imho.
- hhariri 11y ago
  The minor version represents a milestone, currently at 12 and each of these is considerable effort, in terms of decisions and implementation of language features (as well as tooling).
  - mahmoudimus 11y ago
    hhariri - maybe it might be time to get a (rough?) roadmap so that we can plan around it. I know JetBrains is shooting for Q4, but would still be good to track it.
Cyph0n 11y ago
It is officially supported by Jetbrains. I don't really see it as a full-fledged language but rather an extension of Java. I'm planning on trying out on my next Android app.
- hhariri 11y ago
  In what sense don't you view it as full-fledged?
  - Cyph0n 11y ago
    Java interop is a "first-class" citizen, even more so than say Scala.
    - hhariri 11y ago
      But how's that making it less fully-fledged? Actually maybe I should first ask what you mean by full-fledged :)
    - jballanc 11y ago
      The same can be said for Clojure, but I haven't met anyone that would claim Clojure is not a "full-fledged" language. Interop has always been one feature, of many, that languages do or don't have (e.g. C++ interop with C, or C with Assembly).
ex3ndr 11y ago
It seems that Kotlin will be officially presented as next language for Android. IDEA and Android Studio will receive built-in full support for Kotlin in nearest future. I write some parts of Telegram app in Kotlin. Pretty good after plain java. I can't rely on it in production yet (used in build chain). My feelings that React Native + Kotlin could be awesome combination.
- ken47 11y ago
  "It seems that Kotlin will be officially presented as next language for Android." Source?
  - ex3ndr 11y ago
    Just rumours. I hear that Kotlin will be preinstalled in nearest versions of Android Studio. For google Kotlin can be very good language: it designed to compile to javascript, so you can write code for Android and Web in one language. Also JetBrains developing (not a surprise) Android Studio for Google. JetBrains is most qualified company for building Java-based language.
    - hhariri 11y ago
      Are you referring to Android Studio or IntelliJ IDEA? We will be shipping Kotlin bundled in IntelliJ IDEA 15. Regarding Android Studio, we don't develop Android Studio for Google. Google does. We develop IntelliJ IDEA Community Edition, which is the base on which Android Studio is built.
  - m1shk4 11y ago
    it seems they've already started playing with it https://twitter.com/rosshambrick/status/624431306567385088 https://twitter.com/rosshambrick/status/624431306567385088
imd23 11y ago
It was awesome 1 year ago and I think I it supports annotations now, so I'd go for it.
dodyg 11y ago
I started an open source Android project in Kotlin (https://github.com/dodyg https://github.com/dodyg) three years ago so I have witnessed the language evolution from early on. This is what I love about Kotlin: - It is IMHO the best language to develop native application in Android by far. - I was primarily a C# developer (still now) and I could pick up the language in a day. The language is quite small for people that has already known a programming language. - JetBrains is taking their time to get the language right. There is no 'swift syndrome' here. - They are really serious about the Java 100% compatibility. - The IDE support is world class. - It is a really pleasant language to use. - JetBrains is actually using the language for their own products. - The community is friendly and the language designers are approachable. - You can really mix and match Java and Kotlin code in the same project. You don't have to use it only in a green field projects.
- octocoupler 11y ago
  What is the 'swift syndrome'?
  - msie 11y ago
    For me, the swift language is becoming dangerously like Scala. It's becoming a really large language syntax-wise. Trying to incorporate too many features.
  - uknj 11y ago
    I would imagine based on the context of the sentence, that as JetBrains are taking their time with the language, they aren't rushing through developing it further and making mistakes etc. But I could be wrong.
  - y4mi 11y ago
    probably hyping the language beyond reason, despite it being an unfinished product at that time. but the hype was mostly done by the apple disciples iirc, so it might be a little unfair to hold that against the language.
  - J0-onas 11y ago
pjmlp 11y ago
Apparently Google used it for prototyping the new data bindings library in Android. https://www.reddit.com/r/androiddev/comments/3egzq5/so_has_google_started_using_kotlin/ https://www.reddit.com/r/androiddev/comments/3egzq5/so_has_g... For me the language looks nice as alternative to Java 6 on Android (or 7 when targeting 4.4 onwards), but those break@label, continue@label, .... put me off.
- mike_hearn 11y ago
  I'm surprised how often this comes up. What's the big deal with this syntax? It's not even used all that often, only in some special circumstances.
gamesbrainiac 11y ago
I wrote about Kotlin quite some time ago.[0] I have to say that at the time, I was quite impressed by it all. There were some really good features, it had a much smaller dependency compared to Scala, and so packaging a Kotlin application was a lot easier than say an application in Scala. But to answer your question, there are a few benefits and drawbacks of Kotlin as a language and a platform: + World class IDE support. + Simple Language, that isn't as complicated as Scala (but this really depends on what features you end up using) but is expressive nonetheless. + Really good Java compatibility (if that matters to you that is). - Language still does not have a 1.0 (although for a few GUI apps I've done, things are pretty stable) - Language has poor documentation compared to the likes of Java and Scala - Language has few learning resources (but two people in the Kotlin team are working to change that) As far as Android development goes, Android Studio is built on top of the IntelliJ platform (which is Jetbrains' product) so I think you'll get really good android development support for Kotlin although I'm a little indifferent to this. I think that at one point go is going to become the defacto language for Android since google likes to keep everything in-house. [0] http://nafiulis.me/kotlin-koans-i.html http://nafiulis.me/kotlin-koans-i.html
- georgemcbay 11y ago
  "I think that at one point go is going to become the defacto language for Android since google likes to keep everything in-house." As someone who writes Android/Java code for the day job but who prefers coding in Go whenever I have the chance, I'd love for this happen but I doubt it will anytime in the foreseeable future. There's just way too much invested in all of the Android Java Platform/UI/etc APIs which would make little to no sense in Go even if you had good bindings for them. Go will be increasingly supported in Android and it'll get some uptake from people writing games and apps that are primarily OpenGL based, but I just don't see how they could (without investing an absolute giant amount of resources and causing all sorts of developer balkanization), get from where the Android platform is now to an equivalent environment that is properly Go-esque for apps that make heavy use of the higher level platform APIs.
  - johnmaguire2013 11y ago
CookieCutter2 11y ago
Always looking for something more simple than (my current) Scala. - Argued with the developers, they have not clue about Option/Maybe and what it's good for. They offer non-nullable type which solves just one - minor - problem with Null - No deconstruction - Their documentation in the beginning mixed features and planned features without discrimination. Spend a lot of time to find out trying to make them work that the features they've described in detail were fantasies. - With deconstruction I would give it a try in a project.
- CookieCutter2 11y ago
  To clarify: Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs. Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.
  - mplatvoet 11y ago
    The question is, why should this be part of the language or standard library? This can easily be achieved by a library. The Kotlin type system does help though/is essential to correctly implement Option types where other languages like C# can not. The essential part is you can/should define an Option type with a non-null upper bound. Otherwise you would have a Some() that still might contain a null value. So the side affect of solving NPEs you speak of is only there if a language actually supports non-null upper bounds.
    - CookieCutter2 11y ago
      Without proper Option deconstruction and map()/flatMap() syntacic sugar Option code beside map() is not very pleasent to read or understand to my eyes :-(
  - mike_hearn 11y ago
    Non-nullable types aren't just about uninitialised vars, where did you get that idea? Consider that function parameters can also be nullable although you cannot help but initialise them. Nullable types (nonnull is the default) solve the issue of optionality: something that might be there sometimes but also may not be.
hhariri 11y ago
At JetBrains we're using Kotlin on a few projects now. Some of them are internal, some are public facing. In addition, some of our existing (and new) products are now using Kotlin. IntelliJ IDEA 15 will be shipping with Kotlin plugin enabled by default. Kotlin is a tool we created out of need. We're using it and we're relying on it, so I'd say it's got a very good long term viability.
- nchelluri 11y ago
  What was the need that Kotlin arose out of?
  - hhariri 11y ago
    To summarize, we were looking for a language that could cut down our code base (IntelliJ platform and server side tools are written in Java), be concise but still expressive, toolable, as fast as Java, easy ramp-up time, and very important, interoperable with all the existing code base we had. Given the candidates at the time, it was decided to start Kotlin.
    - connor4312 11y ago
      Based on my admittedly limited experience in the JVM world, your needs sounds like Scala's sales pitch. What factored in to your decision to develop Kotlin, rather than going with Scala?
      - pron 11y ago
        The two languages have completely different philosophies. Kotlin is a strict adherent of the Java philosophy[1], a "blue collar language" that adopts only tried-and-true features, with PL research being a non-goal. Scala OTOH, adopts almost every new PL concept, and PL research is very much one of its goals. A quick look at Scala's list implementation will show you how different those languages are. Kotlin is a modern Java; Scala is a Haskell/OOP/macros combo. Yet, I think many of Scala's users will find that Kotlin gives them all they need, in a much simpler, more readable and maintainable language. If, however, you're aching to write type-safe monad transformers, you're bound to be disappointed by Kotlin. [1]: http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf http://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java....
timclark 11y ago
I have used it for a small amount of production code in a mixed Java / Groovy codebase coded using Intellij and Kotlin version 0.11. Kotlin worked well - clear concise code, no null worries and no cast worries. It is peculiarly refreshing to know that my code won't even compile if I try to call a method on null and that Intellij will underline the code in red and suggest a fix. At the time I was using it I would say the quality of some of the code in the Kotlin API was questionable - specifically the jdbc code. I used the parts that seemed sensible and wrote additional code to provide the functionality I needed. I don't think that code is even in the standard API anymore.
- vorg 11y ago
  > I have used it for a small amount of production code in a mixed Java / Groovy codebase Hope first priority was to replace the Groovy rather than the Java.
on_and_off 11y ago
I toyed with Kotlin for Android development. It is very promising. It solves many of my annoyances with Java while keeping what is working. I work in an 8 engineers Android team, switching to Kotlin for our Android app is not on the table at all though. Our huge codebase and complex build script can't be easily retuned to another language, even one compatible with Java and it is an added liability we don't want to deal with. If Google were to adopt it, it could very quickly gain steam for Android development.
staltz 11y ago
I have written Kotlin for an Android app now in production. Having written plenty of Java for Android, Kotlin is really good. It feels like Java in some ways, but helps you more than gets in your way. Nullable/non-null features crush NullPointerException, which are the most common and annoying type of run-time error, this is actually a very pragmatic feature for professional programming. Overall it's less verbose than Java. It's not hardcore on functional programming as Scala is, but adds some FP niceties with its standard library, allowing you to use map/filter/reduce/etc functions on Iterables, which matches very nicely with RxJava if your project is using that already. Also, lambdas make it easier to use RxJava. And IntelliJ IDEA's plugin for Kotlin has a button "Convert Java file to Kotlin", which does a fairly good conversion. The problems I had with Kotlin are minimal. When converting a Java file to Kotlin, I got ClassNameException (I might not remember the name correctly), but you just need to clean and rebuild the project. Lack of support for multiple constructors of a class made me scratch my head, but they added this support in a recent version. Overall Kotlin is a better Java (in less radical ways than Scala). The reason it's feasible for Android is that its size is comparable to small libraries like Retrofit, while Scala is huge and building Android apps together with sbt has been a nightmare for many who tried. The adoption issue is a chicken and egg problem: long-term viability depends on people adopting it, and people want to adopt tools reliable in the long-term. So just do it. Java sucks anyway, I would do anything not to write it.
GeneralTspoon 11y ago
I wrote a small implementation of ListView in Kotlin a while back just to try it out [1]. The pros are pretty cool and some of the issues I mentioned in the readme have been fixed now (multiple constructors). There are still a couple of issues though: - Debugger functionality in IDEA (maybe it's been fixed now?). It was pretty unusable last I tried. - (Android-specific) When extending Android framework classes you don't gain much benefit, since you'll be using the !! operator (override null-safety) a lot, and you'll be somewhat forced into a design pattern that takes away a lot of the power Kotlin offers. If I were to use Kotlin, I'd use it for helper classes and extend View classes, etc. in plain old Java. [1] https://github.com/T-Spoon/Kotlist https://github.com/T-Spoon/Kotlist
rictic 11y ago
After reading Mike Hearn's article on the subject[1], I'm convinced. The next project where I'd normally reach for Java and where I have some freedom in choice of language, I'd pick Kotlin instead. [1] https://medium.com/@octskyward/why-kotlin-is-my-next-programming-language-c25c001e26e3 https://medium.com/@octskyward/why-kotlin-is-my-next-program...
lakedaemon 11y ago
I have been using Kotlin in production for 2 Android apps since october 2013. It made things simpler to write, develop and maintain. One big downside, as of 0.12.1218, is that builds on Android are quite slow (I got 5min builds). But the Kotlin team is aware of the issue and working on it. Once the kotlin builds on Android get fast enough, it will blow everything else out of the water. If Google were to switch from Java to Kotlin for android, I wonder how Oracle would feel...
steedsofwar 11y ago
Yes, I've used kotlin to replace a large legacy Java application. Pretty critical to the business, sat in the middle interacting with. All upstream and downstream systems. Kotlin certain ly made life easier in some places, most importantly it was fast and easy and a joy to work with.
- mahmoudimus 11y ago
  How can I contact you to hear more about your experiences?
  - steedsofwar 11y ago
    pm me :)
bkase 11y ago
We built Roll for Android ( http://tryroll.com http://tryroll.com ) in Kotlin -- we currently have ~17k lines and have been working on it since this Spring. We wanted to iterate on a lot of the software structure we came up with for our Swift iOS app, and for a bunch of pieces we needed a powerful type system. So rather than just stick with Java -- as others have said, it's way too verbose, we started looking at alternatives. We wanted a strong type system. Scala has too much overhead for Android. Kotlin really stood out for us. This document by Jake Wharton at Square https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit?hl=en&forcehl=1#heading=h.v6i4iyf7kkxh https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhC... made the decision easier. So we took the risk. And we love it! The best features: Null type safety! Lambdas can be inlined! No need to be afraid of anonymous inner class overhead on the map/filter/fold of iterables. Reified generics! Extension functions! Single-method interfaces/classes can be represented as lambdas! aka view.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { /* do something */ } }); becomes view.setOnClickListener { /* do something */ } This is great for things like RxJava. Speaking of which, the Java interoperability is fantastic. Any Android libraries we've tried work great from Kotlin. Using these tools, we've built a simple dependency injection framework, a handful of really useful extensions on things like T? (for example monadic bind), a hack for algebraic data types and pattern matching, and of course a fairly complex app. Android Studio's Kotlin support is fantastic (good job JetBrains!) -- it's a pleasure to use. I think Kotlin is totally worth using. The biggest issue for us is the build time. Our build takes anywhere from 1.5 to 6 minutes depending on how much you've changed, but I've found that the type system is strong enough that you don't have to do too many build-change a line-rebuild cycles. We'll be starting a blog soon to talk about some of the stuff we've been doing, but if you can't wait send me a message bkase at highlig.ht if you're interested in hearing more (I love talking about this stuff)
- andrewflnr 11y ago
  That single-method lambda thing I'd really good to hear. Most of my java code is just gluing together APIs, so lambdas don't do much for me unless I can use them with naive java APIs.
- badlogic 11y ago
kcorbitt 11y ago
I've been using Kotlin for about three months to develop an Android application that is now in production. To be honest, I love it. Here's a comment I wrote a few days ago about my experience with it for Android development, from the perspective of someone coming from java: "Seconding Kotlin coming from Java. It takes maybe 2 days to learn everything in the language if you already know Java, and it fixes pretty much all the warts that bother me about Java (the big ones for me are immutable references by default, first-class/higher-order functions, and unnullable-by-default references. Type inference and string interpolations are handy as well). It also has a small enough runtime/stdlib (unlike Scala or Clojure, which I've also tried) to make it practical to use in environments where startup time matters, specifically Android." Compared to Scala, Kotlin is definitely less powerful. But there are three things that concern me about Scala: (1) really long compile times (2) a big runtime (problematic for Android development, although less of an issue on the server) and (3) a "the good parts" syndrome -- that is there are parts of the Scala standard library/common practices that everyone seems to agree are best to avoid. If Kotlin weren't around I think I would look to Scala as my go-to JVM language despite these issues, but given that Kotlin exists and gives me nearly all of the sugar I'd like from Scala without the pain, I'd rather develop in Kotlin. I'm not particularly worried about the community size, although it would be wonderful if the language picked up steam. JetBrains has demonstrated a big long-term commitment to continued development, it's open source, and the Java interop is so seamless that the library ecosystem is a non-issue -- you can use code written in Java without even knowing the difference. And as dodyg says in another comment, the language is really small if you're coming from Java or C#, so there's not a lot of room for undefined or confusing behavior -- it's true that there really ought to be more documentation, but given how similar it is to other languages it should be pretty simple to translate code/examples from Java to Kotlin (IntelliJ even comes with an automatic Java -> Kotlin translator that just works).
- idobai 11y ago
  > a "the good parts" syndrome -- that is there are parts of the Scala standard library/common practices that everyone seems to agree are best to avoid And what are those parts?
thomasloh 11y ago
We're developing out Android app in Kotlin! It is a very promising language and as others have mentioned, the IDE support is superb, first class. Easy learning curve if you already know another language. And since Kotlin also compiles to JS, we're writing our REST api client in it so that our Android app and web product can somewhat share the same codebase. I think Kotlin can potentially go mainstream
pron 11y ago
Kotlin is what Java would have been if it had been designed today. It follows the same philosophy: emphasis on readability, familiarity and maintainability, with PL research and new paradigms being non-goals. It does not introduce new concepts that will revolutionize your development, opting instead to adopt a few well-proven features (null safety, data classes). It is very easy to learn, feels modern and fun. Kotlin offers only a minimal runtime library, instead focusing on making the Java libraries more fun to use. Compilation is fast, and performance is about identical to that of Java. While other languages promise a huge productivity boost (though few deliver) at a high switching cost, using Kotlin is practically free. It interoperates with Java so smoothly that you can gradually transition by freely mixing Java and Kotlin files in the same package. Calling and passing objects from Kotlin to Java and vice-versa is nearly seamless. IDE support is world-class, and Kotlin is the only language other than Java (AFAIK) that lets you use annotation processors, so you can make use of, say, Dagger's compile time verification of dependencies. My favorite feature is smart casting. Inline functions are a poor-man's macros: powerful enough for many things, yet not too clever to be potentially confusing. The only concerns are with adoption rates, and whether the evolutionary progress justifies a new language. I think that the extremely low switching costs make it at the very least worth a try. Why not start with a mixed Java/Kotlin project?
- Bienlein 11y ago
  "Why not start with a mixed Java/Kotlin project?" Think that's a good idea. If you are missing AST transformations you can add Groovy to the game. All three languages in IntelliJ work really fine together. In eclipse you might have to rebuild the entire project when doing mixed language programming. I learned this were a problem with ecliupse, though.
tonyjstark 11y ago
I used it for a small Android project while AndroidStudio was still in beta. Had some minor hickups but it got better with every small upgrade. I was really happy to use it, it's a nice language, actually it was fun to use. When I didn't want to use the documentation I just wrote the code in Java and let the IDE translate that to Kotlin. Two things I liked the most: Null type safety and you don't need to catch every exception if you don't like.
mercurial 11y ago
Another language you may want to look at is Ceylon from RedHat, which has some interesting features (union and intersection types, notably)
- mdaniel 11y ago
  https://plugins.jetbrains.com/search/index?pr=idea&search=ceylon https://plugins.jetbrains.com/search/index?pr=idea&search=ce... Everyone and their cousin can create a language, but without tooling then one is back to authoring in "dumb" editors and I will never ever tolerate that on a team again.
nchelluri 11y ago
After reading this and seeing some Jetbrains blog posts about Kotlin before, I decided to try it out. I downloaded Intellij IDEA Community Edition, and with Java 7 already installed on my machine (OS X 10.10 - I use Java for RubyMine support), I went through the tutorial here: Getting Started with IntelliJ IDEA - http://kotlinlang.org/docs/tutorials/getting-started.html http://kotlinlang.org/docs/tutorials/getting-started.html I started at about 12:55 (download time in Firefox d/l mgr says Intellij d/l completed at 12:58). It's currently 2:13. So ~1h 20m later. Some notes: - First thing I did was install IDEA and then install the Kotlin plugin in IDEA. - Next was creating my first project. - Had to let IDEA know that I have a JDK when creating the project. Took me some time to understand. Once I added this I was able to create a Java project. - The tutorial references creating a Java Module but I didn't know what that meant (still don't really, just know that I had to pick Java from the lefthand-side of the New Project window, and nowhere on my screen is Java Module mentioned). I checked off Kotlin in the Additional Libraries and Frameworks box and off I went. - Also in creating a project, I get an error message that the library I'm specifying doesn't exist, but this doesn't seem to break anything so I ignore it. - Every time I open a project in Intellij I get an error message: "IDE Internal Error occurred. Click to see details and submit a bug report." I click to see the details but the error message just disappears and it seems like there's no actual error at this point, stuff just continues to work. - screenshots are out of date or else different for Community Edition. The wizard doesn't have the "Create Kotlin Library" popups, but some balloons pop up on the top righthand-side and allow me to do the same thing, I think, copying some jars into my project's `lib` directory. - personally I find it slightly confusing that the tutorial asks for the file to be named `app` (as in `app.kt`), and would have preferred if it was called `hello.kt`, but maybe this is some kind of Kotlin convention, so I went with it. - having created the project and the `app` Kotlin source code file, creating the Hello World program was easy and ran as shown in the tutorial. - I did one bit of cleanup in here: I accidentally named my module folder "HellowWorld" instead of "HelloWorld" (though I think the tutorial screenshots reference plain-old "kotlin") and I poked around in IDEA for a few minutes trying to rename it. I couldn't see how, without possibly screwing things up or having to change a few path names. Being worried I'd miss some, I closed the project and renamed the directory in Terminal, and was able to open it up successfully again in IDEA. So now I was finished the Getting Started with IntelliJ IDEA tutorial. I decided to proceed but it was a little bit unclear where I was supposed to go. I would have liked to see a suggested next page link on the bottom of the tutorial, but after clicking around I ended up on the Kotlin Koans page - http://kotlinlang.org/docs/tutorials/koans.html http://kotlinlang.org/docs/tutorials/koans.html . So I followed the Koan tutorial and it asked me to do a git clone of the Koan repo. I did that and opened the directory as a project in IDEA. `ls -l` shows me that the modified time on the koans dir is `25 Jul 01:21`. I believe that's actually the creation time (which is what I want, anyway, so you can see how my progress is going) since I have been modifying stuff up to the point that I wrote this post. (It's now 2:33, btw.) The basic concept of the Koan tutorial is that a bunch of pre-written tests fail and you have to make them pass, one by one. - I was able to run the tests and I find it a bit confusing where I can accidentally switch between running a single test or a whole test file, but I guess that's my inexperience with IDEA showing. - the git repo dir is named `workshop-jb` -- I don't know what this means, but I'd prefer it to be named `koans` - I've finished up-to-and-including `_4_String_Templates` so far, i.e. 4 directories worth of tests. - I haven't yet referenced the `resolutions` branch of the repo, which the tutorial page tells me contains solutions to making all the tests pass. I figured I'd learn more by solving them on my own first. Maybe at some point I'll go back and take a look at the reference solutions. - Running the tests and seeing them fail prints out some help messages about how to make the tests pass. I have found it a little bit confusing navigating back and forth between the reference code they show you at the top of the Koan file that the test executes, the example Java code they sometimes tell you to reference/convert to Kotlin, and the test. In the first, second, and third case, I found the reference code to be confusing -- I couldn't quite tell how it was supposed to help me pass the tests. In all four cases I found making the tests pass to actually end up being quite simple, but I was intimidated by the blob of reference code at the top of the `.kt` file and wasn't always sure what exactly I was to take away from it. I think it is definitely possible to trim these reference bits down and make them very specifically relevant to fixing the tests. I think they are trying to introduce a lot of features of the language at the same time as giving you what you need to pass the tests, and I find it a bit overwhelming. - I've made a few attempts to read through the Reference documentation (http://kotlinlang.org/docs/reference/ http://kotlinlang.org/docs/reference/) and it looks interesting, but ultimately I don't think it helped me to make the test pass at all. I am not sure when/where I'd use it, but it did help me understand one of the labelled break/return comments that is posted somewhere in this comment thread. (Personally, I think that's a cool feature. I first encountered it in uC++ - http://plg.uwaterloo.ca/usystem/uC++.html http://plg.uwaterloo.ca/usystem/uC++.html .) - Last thought: build times are IMO quite slow. I'm changing exactly one short file and it takes several seconds to run the new code, most of the IDEA status seeming to be in the "make" step of the process. Ok, I guess those are my full thoughts for now, I am sorry if this brain dump was too long but I figured someone might get some benefit out of it. For reference, I've been programming for ~20 years now and I was only able to really get started when I first read one of my all-time favorite programming books, C for Dummies :) I was a DOS-fluent 13-year old at the time, and I'd tried reading some others and found them impenetrable. I think the ease of reading and trying shit out and the humor that I found in that book shaped my tastes for learning considerably, and while I don't think every programming tutorial has to be as gentle an introduction as that book was, I think it has a lot to be learned from in terms of programming writing. It's now 2:46. I am tired and going to bed!
stephenheron 11y ago
I had never heard of Kotlin but after looking at the docs I am very impressed. I spend most of my time in the web development world (PHP, Javascript) but I am thinking about starting a small Android project. I have zero Java knowledge so I wonder if it is feasible to jump straight into using Kotlin or to try and learn some Java first?
- gamesbrainiac 11y ago
  Knowing Java is quite helpful if you're building for the JVM, but if your target is JS, then its not much of a problem.
- mahmoudimus 11y ago
  If you want to leverage the whole 100% interoperability of Java (which is a HUGE selling point for Kotlin), I think knowing some Java will be extremely helpful. If you're starting a project from scratch, it might not be necessary if you're building on projects like dropwizard-kotlin, etc.
michas 11y ago
Their choice of name is unfortunate. In Poland "Kotlin" is a brand name of ketchup :) http://www.agrosnova.pl/files/biuro_prasowe/komunikaty_prasowe/2013/Kotlin-hit/kotlin_ketchup_lagodny__450g_medium.png http://www.agrosnova.pl/files/biuro_prasowe/komunikaty_praso...
bartwe 11y ago
Evaluated it but decided to go with C# because it didn't fix a few issues i have with java, specifically generics over value types and structs.
- mahmoudimus 11y ago
  Sadly, this is true. C# is just a superior language. The CLR though is arguably an inferior runtime when compared to the JVM -- maybe it'll catch up.
danieldk 11y ago
I tried Kotlin ~2 years ago and generally liked it. However, one thing that I missed is the possibility to generate Javadoc besides KDoc. This would be useful when writing a library in Kotlin to Java developers who are 'not in the know'. Any idea if this is possible now?
- pron 11y ago
  That is a very cool idea.
- yole 11y ago
  Actually this is being worked on right now: https://github.com/orangy/dokka/pull/32 https://github.com/orangy/dokka/pull/32
virtualwhys 11y ago
Well, let's look at the JVM landscape. First of all Oracle has (finally) picked up the pace in terms of evolving Java and the JVM. This is a bit of a double edged sword for alternative JVM languages since on the one hand JVM improvements (like current SAMs and value types in Java 10) are a big win for all involved, but on the other, Java's evolution is very much a threat to Scala, Kotlin, and Ceylon in particular* Why is Java's evolution a threat? As Java cherry picks functional idioms from, for example, Scala, the motivation for Java teams to pick up Scala is reduced. Arguably Kotlin is in a worse position as its main "problem" is being too similar to Java. Already Java has deprecated the `_` character so shouldn't be any surprise to see `roster.stream().filter(_.getGender() == Person.Sex.MALE)`, land in the language [1]...getting pretty Scala-like o_O Kotlin's window of opportunity is in the next 2-3 years, basically before Java 10 lands. If an ecosystem develops around it (likely one of the reasons adoption rates are so low at present) and their 1.0 comes on the scene soon, they can steal some limelight from Scala, and maybe put Ceylon in the rear view mirror. * Clojure and JRuby are probably safe given their non-Java roots, and Groovy, not sure where it would be without Gradle. [1] https://docs.oracle.com/javase/tutorial/collections/streams/ https://docs.oracle.com/javase/tutorial/collections/streams/
- adrusi 11y ago
  I find it highly unlikely that java would adopt the implicit lambdas using underscores from Scala. The rules regarding precedence themselves are quite simple, but they're not always what new users expect, and cause too much confusion to be appropriate in java. Much more likely is the use of the underscore as an anonymous placeholder in pattern matching. Although even full pattern matching seems a bit much for java in the near future. Pattern matching is more useful than implicit lambdas anyway, the latter being nothing more than a terser syntax for regular lambda expressions to approach the concision of Haskell's point free style without leading to code that's too semantically dense. Pattern matching actually makes new kinds of static guarantees possible.
  - virtualwhys 11y ago
    > I find it highly unlikely that java would adopt the implicit lambdas using underscores from Scala Looks like you're right [1], see Goetz's comment in linked thread. Though that was 2 years ago, the language landscape has changed (notably Swift's arrival and M$ setting up shop on *nix) so Oracle may be a bit more willing to pull the trigger on some easy syntactic sugar to give Java the impression of being somewhat up-to-date with current languages. Underscore is earmarked for something regardless, we'll see.. [1] http://mail.openjdk.java.net/pipermail/lambda-dev/2013-August/010673.html http://mail.openjdk.java.net/pipermail/lambda-dev/2013-Augus...
maikklein 11y ago
How does Kotlin compare to Ceylon? Has anyone written something in both languages and can share their impression?
- gamesbrainiac 11y ago
  Quite similar in terms of feature-sets, but I would say Kotlin has better tooling and Ceylon has better documentation, and tutorials.
- Bienlein 11y ago
  Kotlin is build with interoperability with Java in mind from the beginning. This is not the case in Ceylon. In fact some base types (Int, Long) in Ceylon don't match the corresponding Java type. Kotlin has extension methods which Ceylon has not. Ceylon has reified types, which Kotlin has not. Ceylon went 1.0 in November 2013. So far Ceylon seems not have caught any traction, which is unfortunate as it also is a language well-made in many ways. Kotlin has at least Android development to create some initial traction.
doomspork 11y ago
I've been using Kotlin on-and-off as a Java replacement and I've really enjoyed it. A couple of months ago I used Kotlin to setup a Dropwizard project and it was a breeze so I put together an example on GitHub to serve as a starting point for others: https://github.com/doomspork/kotlin-dropwizard https://github.com/doomspork/kotlin-dropwizard
- mahmoudimus 11y ago
  Need more projects like this! Thank you!
  - doomspork 11y ago
    You're welcome!
talloaktrees 11y ago
I've written an Android game in Kotlin: https://www.youtube.com/watch?v=rISBeabXhvM https://www.youtube.com/watch?v=rISBeabXhvM
antonioleiva 11y ago
I'm currently writing a book about Kotlin for Android Developers:https://leanpub.com/kotlin-for-android-developers https://leanpub.com/kotlin-for-android-developers Overall I think it is a really interesting language for Android (and I guess Java) developers. It's much cleaner and safer. I recommend at least taking some time to play with it and see how it looks. I also have some simple articles at my blog, antonioleiva.com, very basic and perfect to start with it.
- mahmoudimus 11y ago
  Link for clickability: http://antonioleiva.com http://antonioleiva.com
cryptos 11y ago
I've played a bit with Kotlin and have a much better knowledge of Scala, so I could be biased. I like Kotlin, it looks like Java should look like. Kotlin is "just" a better language and not a complete new World like Scala. In Scala it feels often wrong to use a Java lib instead of a Scala lib. So, Kotlin is a smooth upgrade for all Java developers. But Scala is much, much more powerful than Kotlin. Just look at Scala Traits for example. I think, if you have good developers who are willing to learn and to improve, you can get more out of Scala. If you're not that lucky (and I think that is the usual case), you maybe better off with Kotlin.
- mike_hearn 11y ago
  Traits seem like an odd feature to pick. What are you thinking of, precisely? Kotlin interfaces are basically the same: they can contain method and property impls (same as Java 8). Do Scala traits have some additional feature I am unaware of? I admit to a little bias: I've tried to get into Scala several times, but the bad documentation and often overly complex approach puts me off. A lot of Scala features seem like workarounds for other features sometimes. For instance value types in Scala have so many restrictions that they are barely value types at all (e.g. they can have only one member!) and so their primary use case appears to be implementing overhead free extension methods. But Kotlin supports extension methods directly. So whilst implicits+value types may appear to be two features that Kotlin lacks, when you boil it down, it turns out that it has simpler and faster approaches to the same thing. That said, real value classes (with JVM support) will be good when they arrive.
  - cryptos 11y ago
    Kotlin interfaces are essentially the same as Java interfaces. But Traits in Scala are more like (slightly) restricted multiple inheritance. They can have fields, they can be stacked (http://www.artima.com/scalazine/articles/stackable_trait_pattern.html http://www.artima.com/scalazine/articles/stackable_trait_pat...), you can restrict the types where a trait can be mixed in. Value types are useful to enforce certain types which helps to avoid million dollar mistakes like the NASA made when mixing inch and meter as simple floating point numbers. All in all I think, that Kotlin is a good example of the 80:20 rule. You get the most useful concepts and convenience with a low investment. Maybe Kotlin hits a sweet spot in the JVM landscape.
DrMJG_HN 11y ago
There are some people on Livecoding.tv programming in Kotlin. Which project are you thinking of building in Kotlin?
vbezhenar 11y ago
I today decided to try it on small project. I had a lot of class name clashes (wsimport from similar but different WSDLs). I had a nightmare in Java and Kotlin saved me, thanks to its smart import. Properties are much more readable than getters-setters. And there are a lot of sugar here and there, which makes programming more fun. I literally spent may be 5 minutes reading their site. The language is extremely small and intuitive to pick up, if you had some experience with Scala. IDE worked fine. I had few exceptions, but they didn't ruined anything. Refactorings worked. IDE support is very nice.
Bienlein 11y ago
I started looking into Kotlin already when it was M2. Always liked it a lot, because every feature has a reason to exist. Nothing is added without careful thought whether it is needed at all or could be solved in the library anyway. Scala would have been a much more consistent language if the Scala people had progressed in this way as well and Scala code would also be much easier to read. Kotlin seems to have a killer feature which is Android development, which is of course good. But what about internal enterprise development? It makes me think whether Kotlin has enough added value to make people change from a safe haven like Java8 to Kotlin. Sure, much better build times and less problems with code readability when using Akka, Play, Spark with Kotlin instead of Scala. Also Kotlin offers much more power in exploiting the features of those tools compared to Java. But how many people use Akka or Spark? Nevertheless, I wish Kotlin all the best. I will always greatly prefer it over Java or Scala.
fkung 11y ago
In my team, we are currently developing native Android app with Kotlin. At first, I wasn't sure it was going to be successful but when I looked back it was the best decision ever made to my team. Kotlin is short, concise yet powerful. Lambda, and extension are the best features. You can design your API interface in the most expressive way. It help makes communication between objects much much easier. For Android development, it is even sweeter, who likes keep using `findViewById()`. Kotlin-Android-Extension does that automagically. I even write my own HTTP lib for Android entirely in Kotlin. If you like to check it out, here it is (https://github.com/kittinunf/Fuel https://github.com/kittinunf/Fuel)

adriaanm 11y ago
As the Scala tech lead, I'm glad to learn we've finally adopted "almost every new PL concept!" I guess by now everyone will recognize your username and adjust for bias accordingly, but still, how about sticking to the facts?
- rattray 11y ago
  As someone who doesn't follow such things (eg; I don't recognize the "pron" or "adriaanm" usernames, and haven't used Scala or any other JVM language), I found your comment to be a turn-off towards using Scala. That's not the kind of mature tone I'd look for from the tech lead of an open-source language. That said, it is good to know that "pron" was incorrect/exaggerating when they said Scala adopts a lot of PL concepts; thanks for setting the record straight (though I'm still just not sure where Scala stands on that after reading this).
  - virtualwhys 11y ago
    FYI, pron's the author of a would be competing project to Scala's Akka (i.e. competing for share of distributed computing market on the JVM), and takes every opportunity to danger-danger-dragons-be-there on Scala related threads/comments. Saying that, there is always some truth in what pron brings to the table, it's sort of a higher kinded trolling ;-) As for Scala and PL concepts, sure, plenty on offer if that's of interest, but not at all a requirement in using the language. A great example of a highly successful project based on the non-FP-centric aspects of Scala is Spark. See their high performance computing style guide [1], no monad transformers there... [1] https://github.com/databricks/scala-style-guide https://github.com/databricks/scala-style-guide
    - ninjakeyboard 11y ago
      What is a pron? That's like a shrimp?
      - saryant 11y ago
        pron is the author of the GGGP post to the one you replied to.
    - pron 11y ago
      FYI, I had taken "every opportunity to danger-danger-dragons-be-there" Scala — on record — years before I even dreamed of the database company that would one day have an open-source project which would end up competing with Akka (I'm talking 2009/10, while Quasar was first conceived in mid 2013). It was after leading an attempt to adopt Scala at a large organization, which failed because of what I saw as Scala's bait-and-switch marketing: it presented itself as "a better Java" while it really was (and is) a strict-Haskell-with-OOP-and-macros-and-more. We needed a car and got a helicopter. While some would consider a helicopter superior to a car, I think everyone would agree it imposes a completely different set of tradeoffs. So yeah, for a good while I was telling people, listen, it's a helicopter, so make sure a helicopter is what you want (the Scala community’s response was, what is this FUD? Can’t you see it's got wheels?! You can drive it on the ground if you want; you don’t have to take off! To which I responded, but you still can’t take it to a car garage for maintenance, to which their response was, you’re a stupid biased troll!). I don't remember when was the last time I participated in a Scala thread, but that community doesn’t forget. So if I'm damned if I don't, I might as well do: Spark is a good example for a project that would have been better off using Kotlin. They wouldn't have missed any Scala features, would have had better build times, better IDE support and better Java interop (of course, Kotlin wasn’t mature enough to even be considered when that project started). In fact, using Kotlin would have saved them writing 95% of that style-guide[1], which reads like instructions on how to drive a helicopter on the ground without accidentally taking off (Perhaps ironically, that style guide drew derision from the Scala community, who said, you're in a helicopter for fuck's sake! Why won't you take off?!) [1]: No implicits, no multiple argument lists, no Try, no infix notation, no non-math operators, no recursion, no being-fancy-with-monads, no Scala concurrent collections, no Scala collections, no for loops. They don't mention dynamics and structural types, but I think it goes without saying that they're off-limits, too.
      - virtualwhys 11y ago
        Interesting analogy, incredible how Spark drives the Scala helicopter like a car; they seem to have nailed parallel parking ;-) Seriously though, I doubt Kotlin would ever be the first choice for a project like Spark since Scala excels in the DSL department (really without rival on the JVM, and off, only Haskell comes close). Look through Spark source code [1] and you'll see: operator overloading, (sealed) ADTs, exhaustive pattern matching, etc. functionality that you can't even think the thought in in a language like Kotlin. This has nothing to do with monad transformers and other FPisms, just straight DSL power. Finally, to put things in perspective in terms of the mindhsare that Scala and its ecosystem are drawing, IBM is investing over 100 million dollars per year in Spark research and development [2]. Sorry, but that's absolutely massive, maybe there are no dragons? Or if there are, the big players don't seem overly bothered. [1] https://github.com/apache/spark/blob/master/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/dsl/package.scala#L59 https://github.com/apache/spark/blob/master/sql/catalyst/src... [2] https://www-03.ibm.com/press/us/en/pressrelease/47107.wss https://www-03.ibm.com/press/us/en/pressrelease/47107.wss
    - mahmoudimus 11y ago
      I very quickly skimmed through that scala style guide and starred it on Github, but having used both Kotlin and Scala, I am of the opinion that Kotlin (once it reaches v1.0) would remove the need for ~50% of the content of this style guide.

badlogic 11y ago

I can't speak for JetBrains, but from my own experience with Java, Scala and Kotlin, Java interop in Kotlin is a lot better. Scala also offers a lot more features than Kotlin, which is great for highly experienced programmers, but usually means having to subset Scala for mixed experience teams. Kotlin seems to strike a better balance in terms of approachability and expressiveness, and hence being better suited for teams of different experience levels.

hellofunk 11y ago
Where would Clojure fit into this mix? How would its interop compare with Scala or Kotlin, as well as its performance?
- pjmlp 11y ago
  Clojure devs don't seem to care about performance. Just check how the JVM gets the blame for what is essentially Clojure initialization time. There are some in the community trying to improve the situation, but those are kind of forks like Skummet.
  - KirinDave 11y ago
    > Clojure devs don't seem to care about performance. Ridiculous. Clojure devs care a lot about performance. We just care more about correctness.
  - hellofunk 11y ago
    By "performance" I think you specifically mean "startup time." I think there is a big difference between startup time and runtime performance. It is well-known and fully acknowledged by the Clojure community that starting up a Clojure environment and REPL takes a while. But are you also suggesting there is a problem with Clojure runtime performance?
    - pjmlp 11y ago
      I got that understanding given how performance improvements get postponed version after version. Apparently they will be coming on 1.8.
- pron 11y ago
  Clojure's Java interop is smoother than Scala's, but not as seamless as Kotlin's. Kotlin is modern syntax for the same Java APIs and programming philosophy. Scala and Clojure are radically different languages (from Java as well as each other), for better or worse. Kotlin is a modern Java-replacement, while Clojure and Scala have different strengths and weaknesses. That's not to say that you can't write many applications in any of the four languages, but the "feel" of the codebase would be completely different in Clojure or in Scala, while Kotlin would feel the same (but would be leaner).
- nickbauman 11y ago
  After the start time, In my testing, I have never seen Java code that's faster than it's commensurate Clojure code. I've seen the reverse.

JustSomeNobody 11y ago

There's like 9000 programming languages. Not a single one was adequate? Color me skeptical.

blowski 11y ago
It seems that Kotlin was adequate, which is why they chose it. With no idea of the project or the team working on it, I'll assume good faith that they were right.
- JustSomeNobody 11y ago
  Or yak shaving? I remember reading comp.compilers for a long time and people would always post about creating the next great language. They first thing people (usually John Levine) would ask it, "Why does the world need yet another programming language?" Not necessarily to discourage, but to invoke thoughtfulness. There's nothing wrong with new languages. But it seems people are popping them out left and right these days. I think Javascript frameworks are the only thing that come faster. So, do we _really_ need yet another new programming language? Down vote me all you want, but at least I ask the question.
  - carterehsmith 11y ago
    Well, 99% of those are silly little "my first programming language" thingys, and these are easy (if you care about those things) to recognize and ignore. They invariably focus on syntax: removing the semicolon, or braces, or some other trivial thing along these lines. BTW even those can be useful for PL researchers as the language may have an interesting new idea or a new way of doing things. Highly unlikely, but does happen. On the negative side, and this is really bad, some of these may be picked up simply because they are new, and then they just create negative value for people that pick them up (e.g. Coffescript) and fragmentation. Then they get abandoned because there is another newer thing. Sad. Then there a languages made by people with background in creating viable (as in not-just-academic) languages. Typescript and Go comes to mind. These are good and "we" need them. These may add new features to the table, eg generics or union types or goroutines. There is no easy answer to your question, my best answer is "depends on who made it".
- rattray 11y ago
  They didn't choose Kotlin; they created it. (Though, having looked into alt JVM langs recently, I agree that they probably made the right choice in creating something new).
willtim 11y ago
No it's more like 9000 implementations of the same programming language. Only those from academia have ever been new languages.
hhariri 11y ago
Given the constraints we imposed on our decision, I'd say that number was quite lower.

throwaway999777 11y ago

Was there a need to develop a Java IDE in Java to begin with? I can understand dog fooding by building IDE-primarily-for-lang in lang itself. But were there technical reasons? Or maybe Java just was the best alternative [at the time].

hhariri 11y ago
The three founders of JetBrains started a plugin named Renamer out of need, while working with Java code at TogetherSoft. That was over 15 years ago.
pbh101 11y ago
As a user of it, I appreciate that I've been able to use it on three different OS's with minimal adjustment, which Java facilitates more so than other languages, especially other languages which would be reasonable candidates for a thick-client application like this.
mike_hearn 11y ago
It's worked out pretty well for them I'd say. Consider that any developer can write a plugin for it easily, that cannot segfault the entire app, and which runs on all the platforms the IDE supports. That's just one advantage. Higher productivity of feature development is probably another. To see how things could have been different, look at Visual Studio which is still a 32 bit program even in 2015. Users of it complain that it simply can't load big projects without running out of RAM even if their computer has enough. The VS team says they aren't doing a 64 bit port because it's such a big code base and besides, their plugin model is fully native. And of course it's Windows only.
- throwaway999777 11y ago
  > Higher productivity of feature development is probably another. So productive that they had to invent a new language for the JVM platform?
  - mahmoudimus 11y ago
    At the time (~2002?), I think Java was a very reasonable choice for an cross-platform IDE. As more programming language research and different programming paradigms continue to gain mainstream adoption, Java's emphasis on backwards compatibility and stability makes it a bit difficult to change some of the initial design decisions that Java started out. However, since Java is so mature with an even more mature eco-system and an incredible runtime specification (JVM), it made sense to build a modern day "blue collar" language that could be classified as "Java, if it started out today." With that in mind, and some of the same principles that Java was founded on, Kotlin delivers on this promise. IMHO, it is the only JVM language that really does bridge this gap.
  - mike_hearn 11y ago
    They didn't have to - JetBrains has been around for a long time and Kotlin is new. The productivity benefits mostly come from things like fast compile times, garbage collection etc.

mike_hearn 11y ago
Do you actually know Kotlin? It has many features for DSL support, including operator overloading (though not the ability to invent random new operators fortunately), infix notation, a form of exhaustive pattern matching, extension functions, annotation processing, inlineable anonymous extension functions which sounds bizarre but actually is key to defining many DSLs in the language, and so on. It's a different approach to Scala but to say there's no way to do DSLs isn't right. As an example, check out funKtionale. It's a library that adds various functional features like function currying and partial application to Kotlin, entirely by using its DSL features.
- pron 11y ago
  Or our Kotlin actor API: http://blog.paralleluniverse.co/2015/06/04/quasar-kotlin/ http://blog.paralleluniverse.co/2015/06/04/quasar-kotlin/
pron 11y ago
1. None of those features (except sealed ADTs, which really aren't necessary) is missing from Kotlin. The set of Scala features Spark is using is pretty much identical to Kotlin. 2. I don't see how IBM's investment has anything to do with Scala, though. Spark is a great product, and deserves an investment even if it were written in BASIC. 3. Even if Spark did rely on Scala features that aren't in Kotlin (it doesn't), Spark is a library/framework/middleware completely unlike enterprise projects. It is orders of magnitude smaller, for one. That is not to say it isn't awesome, but I wouldn't extrapolate from its choice of technologies (including the language) to the enterprise. 4. Clojure makes writing DSLs easier and with far less magic. Groovy DSLs are also as powerful as Scala's and easier to write. Kotlin DSLs are not as powerful, but are more than enough for Spark. 5. I've never, ever, said Scala is unusable. In fact, I've always said (and believed), it is a very powerful language. I have said that that kind of power is not what most companies want or need, and that that kind of unopinionated kitchen-sink, cutting-edge language is probably not suitable for long-time maintenance in large companies. I completely stand by this. My problem with Scala, again, is not that it's a bad helicopter, but that it insists that it's a good choice if what you want is a car (unless you actually try to drive it like a car -- as Spark does -- in which case you invite the ire of the entire community), and, IMO, it isn't. 6. It's OK to not like your language. It's OK to say it. It's OK to explain why. And it's OK for you to disagree. That doesn't make me biased, and certainly not some kind of bogeyman. It also doesn't justify ad hominem attacks, which -- unlike my criticism of Scala -- are completely unfounded.
- virtualwhys 11y ago
  Good points, as always. > None of those features (except sealed ADTs, which really aren't necessary) is missing from Kotlin. The set of Scala features Spark is using is pretty much identical to Kotlin. I didn't mention implicit conversions, but that's one area where Scala has taken the high risk high reward path. If you look a bit further down on the linked Spark page you'll see the conversions defined [1]. I'd say Spark's style guide is more geared toward Scala consumers and not necessarily library authors (i.e. if you know what you're doing have at it; otherwise keep to a strict subset). Basically, in aggregate Scala's feature set is incredibly powerful; that power (despite the complexity, tooling challenges, and slow builds) is what draws dsl authors to Scala. When IBM throws down an absolute boatload of cash on a project written in Scala, by proxy Scala benefits. Right off the bat there are de facto 3,500 new Scala developers (since the initial IBM Spark team will of course be learning Scala). Furthermore, it's not like competitors aren't aware of this, Spark automically becomes more of a "big deal" as a result, which cannot help but be a boon for Scala. As for other JVM languages, agreed, Clojure has its own supply of awesome, though the lack of (built-in) static types are a no-op here. Groovy, meh, seems to be on a downtrend, I suspect non-immutable-by-default dynamic languages (except of course, javascript) will continue to fall out of favor. Now, Kotlin, it's a nice language. If they can deliver on near Java build times, might just be the Java killer that Scala will never be, or at least not in its current design (where, as you rightly say, there is often more than one way to do the same thing). Let's see how things play out over the next 3-5 years, JVM alternative language landscape is diverse and evolving quickly, good times now and great times ahead... [1] https://github.com/apache/spark/blob/master/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/dsl/package.scala#L115 https://github.com/apache/spark/blob/master/sql/catalyst/src...
  - pron 11y ago
    > I didn't mention implicit conversions, but that's one area where Scala has taken the high risk high reward path. We C++ veterans know that implicit conversions are one of the worst ideas to put in a language. They start simple enough and then they get clever, which is where trouble starts. > i.e. if you know what you're doing have at it; otherwise keep to a strict subset There are few things about programming language design we know, because getting empirical data is so hard. One of the few things we do know (from C++ in the nineties, of course) is that this kind of design doesn't work. The average codebase lifespan is about a decade, during which time people move around and team leads change. Everyone has their own discipline, and by year 5 (usually earlier), the codebase is unmaintainable. Of course, now that C++ has been re-branded and re-purposed as a specialized language for close-to-hardware software, and is used by specialists, it is doing quite well. I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists (although even specialists would be better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea). There is absolutely no reason to be as multi-paradigm as Scala is on the most polyglot platform around, which brings me to: > that power... is what draws dsl authors to Scala. One of the great things about the JVM is its relatively easy inter-language interop. I would use a meta-language made for DSLs (like Clojure, MPS or Xtext) for my DSL, while I'll write the infrastructure in Java/Kotlin. Learning Java and Clojure, or Kotlin and MPS, is easier than learning Scala alone (well enough for DSLs), and the results are cleaner, produce more maintainable code and better error messages (well, I wouldn't say Clojure excels at error messages, but at least the DSL writer has full control over them, and can make them quite good with an extra bit of effort). Also, I'd like to see what those DSL codebases look like after five years of heavy usage (not to mention the error messages Scala spits out, which are completely unparsable to anyone who does not understand how the DSL is constructed).
pron 11y ago
To add to my previous comment (now below), Scala DSLs are without rival only in the complexity of their composition. Clojure DSLs are based on macros. Groovy's are on builders and method-missing. Haskell's are on symbols, monad syntax (do) and lazy evaluation. Kotlin's are built with typesafe builders and inline functions. Scala's are built with symbols, right-associative operators, macros, implicits, monad syntax (for) and possibly even dynamics. Even this most powerful yet most dangerously-clever capability offered by some programming language is supported by like five different Scala features with ten different ways of achieving the same goal. It's absolutely perfect if you want to explore different ways of programming. It's not so great if you need to maintain your DSL for the next 10-15 years in a large organization. Besides, given that the JVM has two of most advanced meta-programming tools anywhere, Xtext[1] and JetBrains' own MPS[2], I wouldn't call any JVM language's embedded DSLs "without rival". All this is about to get even better with Truffle/Graal in Java 9. Saw an interesting talk about easily constructing very efficient languages with Truffle and object algebras at ECOOP[3]. So, especially on the JVM, going for an embedded DSL, let alone one built with very complicated techniques (rather than just Lisp macros) is probably not the best way to use DSLs. It has no advantages and lots of disadvantages. [1]: https://eclipse.org/Xtext/ https://eclipse.org/Xtext/ [2]: https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/ [3]: https://twitter.com/biboudis/status/618402989720662016 https://twitter.com/biboudis/status/618402989720662016

virtualwhys 11y ago
> We C++ veterans know that implicit conversions are one of the worst ideas to put in a language Too late to yank them now, can be disastrous in the wrong (read: beginner) hands, but they're fantistically useful in the dsl department so... > The average codebase lifespan is about a decade maintainability is an issue for the long haul, sure, Scala won't win that battle until it stabilizes, which is at minimum 3 years away when Dotty (Scala 3) comes on the scene. > I certainly wouldn't mind Scala marketing itself -- like C++ and Haskell do -- as a language for specialists Typesafe does the marketing, and as a business they'll never sell their technology short, even if what you say is closer to the truth wrt to specialization. > better off opting for the excellent OCaml implementation on the JVM, or even Frege if Haskell is your cup of tea no users = no dice; doubt either will grab much mindshare in the near-term. Personally I would love to see SML cherry pick the non-crufty good parts of OCaml (including coming implicit parameters) and have that find a following outside of current tiny academic circle it languishes in. > Also, I'd like to see what those DSL codebases look like after five years of heavy usage They probably look a lot different than how they started out as...paraphrasing someone, "you're going to rewrite it [your application] at least 3X" ;-) Basically the entire Scala ecosystem is a moving target, including the language itself. Enterprise outfits looking for a static dependency graph that will work today and 10 years from now should look at Java as the host language. I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle.
- pron 11y ago
  > Typesafe does the marketing, and as a business they'll never sell their technology short, even if what you say is closer to the truth wrt to specialization. I don't think that's selling it short. Accurately describing your product only prevents people who aren't really your target -- like me -- from being disappointed and telling the world about it, while it helps attract precisely those people who would be most excited about it. Also, I think Typesafe realize now that there is not much money to be made in developing and supporting a programming language (ironically, there is some to be made -- though not too much -- supporting specialist languages; see Ada and Matlab). That's why they want to change their name, right? > no users = no dice; doubt either will grab much mindshare in the near-term. That's splitting hairs a bit; Scala doesn't exactly have mass appeal either. We're talking about the difference between tiny and small. > I doubt Kotlin will be able to deliver the same guarantees, but if it can, watch out Oracle. I know they're trying to. Also, I know Oracle actively encourages alternative JVM languages. Their product is the Java platform, which currently -- to be honest -- is not too far from being the same as Java the language (all alternative JVM languages combined don't amount to 10%, or possibly even 5% of the JVM ecosystem). But they wouldn't mind if that changes. Their research team working on Graal, HotSpot's next-gen JIT, coming to OpenJDK in Java 9, spends as much time on making sure it runs Ruby, R, C, Python, and JavaScript well as it does on making sure it runs Java well. I know Oracle's Java team isn't all too happy about it, but I also know that that's what Oracle wants.