Ask HN: Has anyone here programmed in Kotlin? What do you think about it?
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=
202 comments
[ 4.5 ms ] story [ 279 ms ] threadIt's only on version 0.12.213. Bit premature to judge long term viability imho.
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.
Source?
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.
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.
But I could be wrong.
but the hype was mostly done by the apple disciples iirc, so it might be a little unfair to hold that against the language.
However, Python 2/3 is a better example for breaking backwards compatibility.
Kotlin was developed in the open from much of its development and you can see how the language evolves based on the feedback of early adopters. There is no rush to 1.0 until they feel they got the right mix of features.
I just think the way Jetbrains approached the development of the language is more responsible and it bodes well for future iteration of the language.
Not that Kotlin is introducing anything like this, but, I wonder if this sets a precedent going forward for popular programming tooling vendors to evolve as the primary distribution point for introducing new programming language research and paradigms to the industry.
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.
+ 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
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.
You nailed it. I think that this is ultimately something that JetBrains must stress in their documentation and have extensive examples on how to go about doing this if Kotlin is to get much more widespread adoption.
- 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.
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.
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.
If you allow null as a return type you need to check for null if you want to use it or not. If you return Option[_] people e.g. just use map() on the return value and then map().map().map().map() on that etc. With Option your code usually does not care to check until the very last moment. Sorry my English is not good enough to make the point :-( And I know, saying "You need to use Option (and Applictives etc.) some years to grok" sounds arrogant and unsatisfactory. But I would not go back to a language without Option (and Applicatives etc.) usage in it's culture.
Since Kotlin can leverage JVM libraries, why not use Google Gauva? https://code.google.com/p/guava-libraries/wiki/UsingAndAvoid...
I personally would listen instead of attacking me.
Kotlin has deconstruction:
Their documentation did indeed commit this sin when I first started using Kotlin last year. It's been cleaned up considerably and this is no longer an issue (except, I think, for the mysterious modules which appear to be an IDE specific concept).2. Sorry, wording is vaque, often deconstruction is
val MyValueObject(a,b,c) = myObject
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.
Given the candidates at the time, it was decided to start Kotlin.
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.
Ridiculous. Clojure devs care a lot about performance. We just care more about correctness.
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?
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).
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....
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).
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
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.
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...
[2] https://www-03.ibm.com/press/us/en/pressrelease/47107.wss
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.
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.
> 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...
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).
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.
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.
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/
[2]: https://www.jetbrains.com/mps/
[3]: https://twitter.com/biboudis/status/618402989720662016
Color me skeptical.
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.
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".
Or maybe Java just was the best alternative [at the time].
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.
So productive that they had to invent a new language for the JVM platform?
... and when you went to the Scala developers, they said "no, we aren't interested in such improvements at all, even if you implemented them yourself"?
Hard to imagine...
http://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-needs...
The nice thing about that post is that they (Jetbrains) are pretty honest about the whole things e.g.
"First and foremost, it’s about our own productivity."
"The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA. "
"The final point is less obvious but still important: new programming languages is a topic that many people really enjoy talking about, and the first days that have passed since we’ve unveiled Kotlin prove that."
"And we’d like to reiterate that our work on Kotlin does not in any way affect our investment into other development tools, and in particular the Scala plugin. If you’re already happy with Scala and have no need for another new language, we’ll continue to do our best providing you with first-class Scala development tooling."
I really dislike it. Couldn't it at very least have a space between keyword and label?
Also I still miss a good build tool. I mean Maven really sucks, Gradle is kind of okai, but there is no support of autoreload project on change (like sbt has via sbt-revolver or playframework internals) however that is mostly helping web development.
Also some other things aren't really written out, like threading or some kind of Akka stuff. Also these days a language needs Dependency Injection, a good Integration with JSR330 would be great.
Also for some functional workflows something like pattern matching would be great and a @tailrec annotation like scala.
And please, for gods sake, remove labels and break/while.
Why?
> I mean Maven really sucks
Why?
> Also these days a language needs Dependency Injection
There's plenty of JVM libraries that provide it. Why does a language need to provide it?
XML based Build Tool, I mean seriously? It should at least be somehow human readable.
A language should need a sane integration of it, not the library itself. Okai DI is definitly somewhat that isn't needed, but a good integration is still suitable.
I mean good Multithreading lives in RxKotlin which is based on RxJava, however I still think that Threading or some kind of Library which should handle mutli prozessors / async capabilities should live INSIDE the language (like go, erlang or lots of others).
I mean currently Java9 will get a lot of new things which will definitely help out Scala to compile faster and Java10 will bring these closer. So there is no real reason for a language that still lacks a lot of stuff. As already said, Kotlin is small, on some edges thats good, on some it's just too small and I don't get it why they built while, break and continue into a somewhat functional language. Especially when while, break and continue is really hard to handle / read.
The only issue I had was to ignore Package class to make pit work
For DI, Dagger2 works fine with kotlin
For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)
Have you opened up an issue on Quasar's repo (https://github.com/puniverse/quasar) so Parallel Universe can track this for a possible milestone?
Just put something like this in your gradle.build file :
apply plugin: "info.solidsoft.pitest"
pitest { targetClasses = ['org.lakedaemon.suggest.', 'org.lakedaemon.compress.'] //by default "${project.group}." excludedClasses = ['org.lakedaemon.compress.decoders.DecodersPackage', 'org.lakedaemon.compress.decoders.EncodersPackage'] avoidCallsTo = ['org.apache.log4j.', 'org.lakedaemon.L.', 'org.slf4j.', 'java.util.logging.'] pitestVersion = "1.1.4" //not needed when a default PIT version should be used threads = 4 outputFormats = ['XML', 'HTML'] enableDefaultIncrementalAnalysis = true testSourceSets = [sourceSets.test/, sourceSets.integrationTest/] mainSourceSets = [sourceSets.main/, sourceSets.additionalMain*/] }
That having been said, I think your concerns will be addressed, _eventually_, but JetBrain is not trying to disrupt Java or its ecosystem before mainstream adoption of the language.
Re: async capabilities like Erlang/Go, until the JVM can support continuations, an industry standard solution like bytecode instrumentation, which Java9 will improve on, will entrench libraries like Quasar / RxKotlin to be basically drop in. These libraries provide seamless interoperability with existing synchronous libraries (see https://github.com/puniverse/comsat) to get around the fact that Erlang's/Go's async capabilities are not built-in to the language.
Why?
> XML based Build Tool, I mean seriously? It should at least be somehow human readable.
It's entirely human readable in my subjective opinion. At the very least, it's as human readable as HTML...
> A language should need a sane integration of it, not the library itself.
Any language which has constructors already has the best DI integration available.
No reason to bake it into the language -- and as you can see from comparing the Java and Kotlin sample code, there is a reason for a language that let you write Groovy-like DSLs.
http://docs.paralleluniverse.co/quasar/
Go-style channels and goroutines are built on green threads which Go/Erlang has, but the JVM does not have. One way to work around this is to use fibers and continuations which is what Quasar is doing.
Why?
I think after a while one gets tired of using XML as a configuration language. It's verbose and not the easiest to read. Beyond that, we used to find ourselves in dependency hell with maven pretty frequently, though that hasn't happened to me in a few years.
The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself.
I've written a maven plugin, and the documentation/support was rather poor. I also found myself having to use an older version of various plugin libraries in order to write proper tests for the plugin. It took me a couple of weeks. Had I done all that in Gradle, I could have just thrown in a few lines of groovy and probably finished in a day.
That said, it's stable and well known. Gradle seems to have the momentum and increasing mindshare, but you probably won't get fired for using maven.
[1] https://github.com/takari/polyglot-maven
Weird.
Verbose and unreadable are not contradictory descriptions. In fact, they are more complementary descriptions -- there is a reason that in natural languages one of the most frequent recommendations for clear and readable writing is to be concise.
Excess verbosity is bad for readability.
"Probably"? "Thrown in"? Perhaps you can cut and paste build scripts between Gradle projects, but write anything more than "a few lines" in Groovy and you're looking at huge maintenance problems, like something that evaluated as ["abc", "defg", "hij"] suddenly becoming ['a', 'b', 'c'] for reasons that become apparent only after hours of printing debug messages.
You'll hit that with Gradle, Ivy, Leiningen, SBT and Buildr too.
> The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself.
I'd also call that it's biggest strength. Maven POMs are only ever declarative. I've never hit a FOSS project using Maven that I couldn't build, but I've hit plenty using SBT or Ant that I had to tweak to build.
> I've written a maven plugin, and the documentation/support was rather poor.
I had the same experience with Gradle's DSL documentation, although having a look at it now, they've dramatically improved it since then.
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.
Hope first priority was to replace the Groovy rather than the Java.
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.
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.
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
[1] https://medium.com/@octskyward/why-kotlin-is-my-next-program...
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...
Kotlin certain ly made life easier in some places, most importantly it was fast and easy and a joy to work with.
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-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
becomes 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)
I'm sorry that I didn't make it clearer in my post (I'll edit it), but the thing I really appreciate is that I can use functional methods on objects (like map, fold, filter on iterables or our monadic bind method on optionals) and pass lambdas because I know it will be inlined. The inlining -- which should always happen this particular scenario (please correct me if I'm wrong) -- makes using these methods super cheap!
> Lambdas can be inlined!
Kotlin's inline functions are meant to serve as a poor man's macro system (to implement simple control structures) and/or for argument type specialization -- not to save the "inner class overhead" because, guess what? There isn't one! While HotSpot's JIT will certainly not inline lambdas in every circumstance (though it's getting better), it will inline them in all cases where Kotlin's inline functions can be used (and many others where they can't). It is possible, however, that inner classes do have some overhead on Android.
> Reified generics!
Kotlin does not reify generics, and like in Java, that's a good thing! Java's erased generics are precisely what makes polyglot interop easy.
Again I wasn't being very clear, sorry about that: Kotlin doesn't always reify generics, but it can for functions you mark as inline if you want (it's useful!). Check out the inline function docs!
Also, there are few compilers anywhere with optimizations as powerful as HotSpot :) And HotSpot compilation is only getting better and better. Java 9 will even let us use Graal as the optimizing compiler (i.e. instead of C2), which can do this: https://twitter.com/ChrisGSeaton/status/619885182104043520
I use Kotlin for non-Android projects with Maven, so incremental compilation works. Build times are not a significant issue, though the Kotlin compiler is still not as fast as the Java compiler is. I noticed from doing hotswaps when debugging processes that Kotlin seems to still compile too much, even when in incremental model. So I hope once JetBrains get stability under control they can spend some time optimising.
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).
And what are those parts?
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
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.
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
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 .
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...
Then there's the warning about unregistered VCS roots. I confess that rather than looking into the meaning of this warning and trying to fix it, I just uninstall the VCS plugin (git in my case) and do revision control outside of IDEA (TortoiseGit).
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?
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?