This article misses something I feel is really very important: <i>Kotlin is just Java</i>! Like, granted, I'm probably a better-than-average developer, but I was turning out well-factored, clean, readable, 100% Java-interoperable code in Kotlin in about a day. Over time I've added more Kotlin-specific stuff (like their way nicer-feeling collections APIs) but for real, it's just...Java.<p>But it's smarter Java. It gets out of your way. If you understand Java, the 1:1 mapping between Kotlin and Java is trivial. I can tell you what the auto-generated Kotlin code from the IntelliJ helpers is gonna look like when you convert Java to Kotlin and it's just...obvious? The only thing I have ever had even the slightest trouble with was how to take a var (which I understood immediately to be a backing field with getter/setter methods under the hood, both because the doc says so and because IDEA says "from getFoo/setFoo" when importing Java so it's an obvious intuitive leap) and apply a Hibernate Validator attribute only to the getter. It was a hole in the docs at the time, but I figured it out: `@get:Something()`. If that's the only thing that gets an experienced but largely out-of-the-game Java developer a little head-scratchy, this should be a slam-dunk type of thing for somebody who writes Java every day.<p>Maybe it's harder for Android. (I think you should write React Native for Android for basically anything you can--and I have, I released a Google Play app a couple weeks ago that I really should get around to marketing--because while I am down with Kotlin,I also like being able to actually share code everywhere.) But Java-to-Kotlin is a no-brainer, in my book, at literally any Java shop not targeting, like, Java one-dot-ancient.
><i>"Developers need to learn Kotlin well enough to confidently read the language. While a few developers will self-teach themselves, teams will still need to set aside training time for everyone to get up to speed. New developers will need to learn Kotlin, and a one and done training won’t be enough. In addition, current developers who are trained but rarely touch Kotlin may need a refresher if they move to a part of the code requiring Kotlin. This means onboarding is slower and you may lose some velocity."</i><p>Are engineering teams at Pinterest really so weak that going from Java to Kotlin—an extremely similar language—is a major hurdle? The entire mindset of this article is alien to me.
I'm impressed by the even handedness of the article.<p>Normally, I wouldn't even think about using a language developed and championed by a litle Czech company, however, JetBrain's tooling is incredible and I gladly give them money every month for R#.<p>On the other hand, usually I would think that the language being endorsed by a major company for their platform was a big plus, but the way that Google drops products and initiatives, their support means little.<p>So yeah, I trust JetBrains a lot more than I trust Google and if I ever decide to bite the bullet and start developing for Android, Kotlin will be my first choice.
Well maybe, but <i>the</i> Steve Yegge wrote this:<p><a href="https://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better-than-whatever-dumb.html" rel="nofollow">https://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better...</a><p>Obviously these guy love Java. This, frankly, I can't understand. I've hated Java for 20 years :) However if you love Java, obviously you don't need to switch to Kotlin. If like 99% of people used to leaner languages, you find Java unbearably verbose, ugly, etc. Kotlin is a godsend.
Kotlin is here to stay, it's a pleasure to code in it. The same way ObjC gave way to Swift and I also enjoy coding in it. They both are the only languages I use today for any development. I don't care about tail-call-whatever, functional-whatever or monad-whatever, I just care about a nice and clean syntax that gets out of my way to get the job done in less time. The rest will be improved by people way more intelligent than me in whom I trust, backed by two of the biggest players in the development world, Google and Apple.
If it takes a week till new developer feels really comfortable, then it is quite fast and total non-issue. The article spins it as some kind of problem you need to be aware of, but realistically it looks like drop in a bucket compared to what it takes till one get really comfortable with existing codebase, company standards, processes and what not.
This reminds me a lot of Swift's early days. Build times, dev stability, learning curve, static analysis (remember the esoteric compile/lint errors...) even reversibility (i.e. Apple had a tool to convert from Obj-C to Swift but not the reverse) were issues that were brought up. If Kotlin hopefully follows Swift's path then these will get ironed out over time.
This article is most likely written by someone who does not like Kotlin but has to live with the fact that he has to use it. Let's see some invalid points:<p>> If you’re going to use Kotlin in your code base, you’ll need to teach almost every developer on your team how to use it.<p>Not true. Java and Kotlin can be used on the same project and Kotlin also has seamless Java interop. If you don't want to write Kotlin you don't have to. It is also easy to read for other devs so readibility is not an issue.<p>Then the writer goes on and on how the velocity is affected by learning Kotlin but misses the point: you don't have to burn any bridges by using it.<p>> When I realized very few developers actually saw the developer velocity gain, I was left with a bit of a, “so what’s the point” feeling.<p>Then the op should question the capabilities of his developers. I came from a Java background and after several weeks of Kotlin exposure my productivity skyrocketed. It helps if you have some FP background but you can learn it on the way. Currently the whole team writes Kotlin code and looking back at previous sprints I can say that the velocity increased by a double digit percentage.<p>> Kotlin accounts for about 25 percent of our clean build time and 40 percent of our incremental build time.<p>Then the op has some serious Gradle configuration problems. We also had this then tweaked Gradle (upped the version, started using parallel builds, etc) and now the difference is minimal. You are also better off with tools like JRebel even if you work with Java.<p>> Not being familiar with Kotlin, the developer immediately assumed Kotlin was causing the problem and lost time investigating what was a simple fix. This “weirdness” combined with the actual stability issues means there’s significant maintenance time lost.<p>I've been using Kotlin for more than a year and I only had a single stability issue (and it was an IDEA plugin problem). Kotlin works amazingly well with other libraries and after using it for several months I felt that I never want to go back to Java.<p>Maybe the op's issues are with the Android ecosystem or a bad development team, and not with Kotlin itself since we use it on the backend and we don't see the problems mentioned in the article.<p>The only valid point I've seen in the article is the lack of static analysis tools and as the article states it will get better.
Steve Yegge recently rose from the proverbial grave to build a case <i>for</i> Kotlin: <a href="https://steve-yegge.blogspot.co.il/2017/05/why-kotlin-is-better-than-whatever-dumb.html" rel="nofollow">https://steve-yegge.blogspot.co.il/2017/05/why-kotlin-is-bet...</a>
Apple, and iOS developers, need Swift a lot more than Google needs Kotlin. The main benefit to Google is that Kotlin provides a ready-to-deploy lifeboat in case Oracle is able to make significant intellectual property trouble for Google.
Well written and thought out, meta issues such as training are rarely mentioned in comparison pieces but do play an important role in the decision process
Well written article. Most of the points made are common sense... but I think often the points are glossed over and we don't stop to think about it.