This article misses something I feel is really very important: Kotlin is just Java! 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.
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.
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.
We had a few places where we had some headscratchers.
First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a dynamically typed language like groovy has some advantages there.
Closed classes by default can make some testing a little more difficult. We have continued using Spock rather than moving our tests to Kotlin, and there are a few places where we compromise our design until we can figure out a better way. (Yes. Dependency Injection and less coupling is the answer, alongside adding a level of abstraction in between third parties. The devil is in the details.)
In general, we like it and are planning on expanding our use, but conversion has had its challenges.
I mean, look at JSX, which is just JavaScript. Coming from all the crap templating languages pulled off the last 10 years it is basically god sent. Still people hate around and they always will, that's what we do, we lern stuff and if it gets obsolete, we want to keep it because it fed us for years.
The other really important thing: You can have both in one project. [1] You can gradually convert your existing Java project to Kotlin; there's even a menu item in IntelliJ to straight up convert a Java file into Kotlin.
It's not that much harder for Android. In fact, with Anko, there's even more reason to pick it up for Android. The pain point in using Java is huge for Android because a lot of Android functionality adds more boilerplate.
>"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."
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.
Some context I think might not have made it to the Hacker News readers. We use Kotlin at Pinterest, we were one of the two teams talking about the value of Kotlin when google announced support at IO https://www.youtube.com/watch?v=fPzxfeDJDzY.
We don't expect to be able to hire Android engineers that are familiar with Kotlin to the level of expertise we expect with Java. We do expect everyone to be able to work with any part of the Android code base and not be guessing at how of the concepts many android devs aren't familiar with work. If you don't consider the time for engineers to learn this, you are not considering some of the cost of adopting. If you think it's not that big of a deal, then go for it, we did.
I'm a lone wolf in the Java space, and I must say that this one really hits home. I've been dealing with so many Java devs who are unwilling to approach anything else that I am sick and tired of their whining! These people are even moaning about JavaScript. I mean - Come On! (Job style)
There's a certain type of developer that's impossible to miss on developer-focused social media: the thrill-seeker which loves learning new programming languages, building an apparently impressive-looking project with them and writing blog posts about how everything was awesome.
Introducing a new language to an organisation is completely different from the above and it's nice for a change to see blog posts that also consider the long-term sustainability of a solution, maintenance costs, potential staffing and training difficulties, etc. These are things that are very important for a mature project.
Going from Java to Kotlin does have a penalty of learning, same as going from C to C++. I think going to Java to Kotlin is easier if you have Swift or Go as language experiences.
I'm impressed by the even handedness of the article.
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#.
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.
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.
JetBrains is a mostly Russian company. It is registered in Czech republic, as business conditions in Russia are... erratic, to say the least, but most of their founders and employees are Russians, and their prime engineering unit is in St. Petersburg, Russia.
Jetbrains is not little and I don't even understand why anyone would think they are little. Just because it is nor western (or american) does not mean it is small.
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.
Agreed. A lot of this has to do with where you came from and what you were used to previously.
I initially switched to Java in the late 90's from C++. At that time, C++ was just achieving (imo) its densest, most arcane features that were making me crazy. What I really wanted was a C+- or something that didn't force a bunch of stuff I didn't need on me. Java was exactly what I needed at that point.
After 15-20 years of Java, I recently switched to full time Javascript development and woah! It was like the freshest breath of fresh air. What, no types if I don't want them? Closures and protoype inheritance? Yes, Omg!
Imagine my dismay when I was first introduced to TypeScript! My code looked just like Java again. :( Seriously, I understand the reasoning behind TS and getting into it a little further convinced me it wasn't too bad after all. Again, what are you used to has a lot to do with your state of mind as a dev.
Any language that lets developers express their intent in the way they like is great. Kotlin, Scala are like the JS & TS of the Java world. All good (as long as they work!).
The problem with Yegge's post, is he opens up with these arguments:
"Unfortunately -- for long complicated legacy reasons that nobody cares about -- some of Android's core APIs really are bad. I mean baaaaad bad. Shut the book, take a deep breath, and go out for coffee bad."
"It turns out the perfect killer app here -- and this brings us full circle -- is Android's crappy Red Light APIs."
He then concludes with:
"Kotlin manages to help you route around just about all of Android's Red Lights, and turns the experience into something that on the whole I now find superior to iOS development. "
... but offers no compelling reason how Kotlin supports this conclusion.
i didn't get any sense that they loved java - note that none of their (very fair!) caveats dealt with kotlin as a language, just with the undeniable fact that the tooling ecosystem was a lot more immature than java's, and could cause you unexpected problems.
"It's like Java" and
"It's got one hell of an IDE"
Um, okay. I guess?
There are other languages that are "like Java", and they don't count?
So, basically all it takes to get a language adopted is a snazzy IDE? Wow. I guess we need to remember to design new languages to optimize for IDE integration rather than actual programming.
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:
> 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.
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.
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.
> 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.
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.
> Kotlin accounts for about 25 percent of our clean build time and 40 percent of our incremental build time.
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.
> 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.
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.
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.
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.
I'm not against Kotlin, but seemless interoperability and the ability to have both in the same codebase simultaneously does not, in general, mean you can have a lot of your devs skip learning it. In fact, in my experience, projects that were using two interopable languages meant you had to be a lot more of an expert in both. The cognitive overhead of flipping back and forth when just switching files was painful because the two languages were just similar enough. If you had some very silo's portion of the code that you could leave your Java people on, then it's possible, I've just never seen that in practice.
> 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.
Until you have to trace a bug through both codebases.
Dual interop codebases never work. A computer language simply takes up too much mental space to know even one language well and stay up-to-date on it.
Yes, I know there are exceptions, but I have yet to actually meet and work with one.
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
[+] [-] eropple|8 years ago|reply
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.
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.
[+] [-] ebiester|8 years ago|reply
First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a dynamically typed language like groovy has some advantages there.
Closed classes by default can make some testing a little more difficult. We have continued using Spock rather than moving our tests to Kotlin, and there are a few places where we compromise our design until we can figure out a better way. (Yes. Dependency Injection and less coupling is the answer, alongside adding a level of abstraction in between third parties. The devil is in the details.)
In general, we like it and are planning on expanding our use, but conversion has had its challenges.
[+] [-] k__|8 years ago|reply
Nobody cares.
I mean, look at JSX, which is just JavaScript. Coming from all the crap templating languages pulled off the last 10 years it is basically god sent. Still people hate around and they always will, that's what we do, we lern stuff and if it gets obsolete, we want to keep it because it fed us for years.
[+] [-] buremba|8 years ago|reply
[+] [-] prophesi|8 years ago|reply
[1] https://kotlinlang.org/docs/tutorials/mixing-java-kotlin-int...
[+] [-] muzani|8 years ago|reply
[+] [-] xiaoma|8 years ago|reply
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.
[+] [-] ryanator|8 years ago|reply
Some context I think might not have made it to the Hacker News readers. We use Kotlin at Pinterest, we were one of the two teams talking about the value of Kotlin when google announced support at IO https://www.youtube.com/watch?v=fPzxfeDJDzY.
The article is meant to show the reasons we considered not to use it. The language is very similar to Java and we've written some about how even "the grumpy java developer" can learn it https://medium.com/@Pinterest_Engineering/kotlin-for-grumpy-....
We don't expect to be able to hire Android engineers that are familiar with Kotlin to the level of expertise we expect with Java. We do expect everyone to be able to work with any part of the Android code base and not be guessing at how of the concepts many android devs aren't familiar with work. If you don't consider the time for engineers to learn this, you are not considering some of the cost of adopting. If you think it's not that big of a deal, then go for it, we did.
[+] [-] strictfp|8 years ago|reply
[+] [-] blub|8 years ago|reply
Introducing a new language to an organisation is completely different from the above and it's nice for a change to see blog posts that also consider the long-term sustainability of a solution, maintenance costs, potential staffing and training difficulties, etc. These are things that are very important for a mature project.
[+] [-] ramensea|8 years ago|reply
[+] [-] nicholassmith|8 years ago|reply
[+] [-] aembleton|8 years ago|reply
[+] [-] scarface74|8 years ago|reply
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#.
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.
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.
[+] [-] atemerev|8 years ago|reply
[+] [-] watwut|8 years ago|reply
[+] [-] btian|8 years ago|reply
[+] [-] jmnicolas|8 years ago|reply
[+] [-] wazoox|8 years ago|reply
https://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better...
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.
[+] [-] eludwig|8 years ago|reply
I initially switched to Java in the late 90's from C++. At that time, C++ was just achieving (imo) its densest, most arcane features that were making me crazy. What I really wanted was a C+- or something that didn't force a bunch of stuff I didn't need on me. Java was exactly what I needed at that point.
After 15-20 years of Java, I recently switched to full time Javascript development and woah! It was like the freshest breath of fresh air. What, no types if I don't want them? Closures and protoype inheritance? Yes, Omg!
Imagine my dismay when I was first introduced to TypeScript! My code looked just like Java again. :( Seriously, I understand the reasoning behind TS and getting into it a little further convinced me it wasn't too bad after all. Again, what are you used to has a lot to do with your state of mind as a dev.
Any language that lets developers express their intent in the way they like is great. Kotlin, Scala are like the JS & TS of the Java world. All good (as long as they work!).
[+] [-] clumsysmurf|8 years ago|reply
"Unfortunately -- for long complicated legacy reasons that nobody cares about -- some of Android's core APIs really are bad. I mean baaaaad bad. Shut the book, take a deep breath, and go out for coffee bad."
"It turns out the perfect killer app here -- and this brings us full circle -- is Android's crappy Red Light APIs."
He then concludes with:
"Kotlin manages to help you route around just about all of Android's Red Lights, and turns the experience into something that on the whole I now find superior to iOS development. "
... but offers no compelling reason how Kotlin supports this conclusion.
[+] [-] zem|8 years ago|reply
[+] [-] bsder|8 years ago|reply
"It's like Java" and "It's got one hell of an IDE"
Um, okay. I guess?
There are other languages that are "like Java", and they don't count?
So, basically all it takes to get a language adopted is a snazzy IDE? Wow. I guess we need to remember to design new languages to optimize for IDE integration rather than actual programming.
[+] [-] Entangled|8 years ago|reply
[+] [-] smichel17|8 years ago|reply
[+] [-] watwut|8 years ago|reply
[+] [-] mephitix|8 years ago|reply
[+] [-] edem|8 years ago|reply
> 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.
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.
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.
> 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.
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.
> Kotlin accounts for about 25 percent of our clean build time and 40 percent of our incremental build time.
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.
> 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.
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.
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.
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.
[+] [-] gleenn|8 years ago|reply
[+] [-] bsder|8 years ago|reply
Until you have to trace a bug through both codebases.
Dual interop codebases never work. A computer language simply takes up too much mental space to know even one language well and stay up-to-date on it.
Yes, I know there are exceptions, but I have yet to actually meet and work with one.
[+] [-] SonOfLilit|8 years ago|reply
[+] [-] Zekio|8 years ago|reply
[+] [-] Zigurd|8 years ago|reply
[+] [-] AzzieElbab|8 years ago|reply
[+] [-] manquer|8 years ago|reply
[+] [-] swsieber|8 years ago|reply
[+] [-] atemerev|8 years ago|reply
[+] [-] 35bge57dtjku|8 years ago|reply
[+] [-] edem|8 years ago|reply
[+] [-] utkarshsinha|8 years ago|reply
[+] [-] klancaster|8 years ago|reply