21 ms·

The case against Kotlin

142 points by PleaseHelpMe 9y ago

Zigurd 9y ago
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.
edem 9y ago
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.
- bsder 9y ago
  > 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.
  - edem 9y ago
    Not true. Our codebase is java/kotlin and it works.
- gleenn 9y ago
  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.
swsieber 9y ago
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.
scarface74 9y ago
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.
- jmnicolas 9y ago
  I'm curious to know what R# does for you (honest question). At work I use Visual Studio but I never felt the need for an addon, my needs are met.
  - scarface74 9y ago
    I know this might come across as an infomercial. I'm really just a fanboy of JetBrains. To give even more context, I'm also a one handed typist (not by choice). So the various R# shortcuts really help me code faster. Some of my most used patterns 1. Create a class 2. Type ctor + tab - create a constructor (VS) 3. Type a parameter type and a variable (R# auto completes with a reasonable name) 4. Type Alt+Enter+Enter. R# creates a private class field and assigns the parameter to the private field ---- I need to create an equality operator for a class. This is the standard c# pattern: https://msdn.microsoft.com/ru-ru/library/ms173147(v=vs.80).aspx https://msdn.microsoft.com/ru-ru/library/ms173147(v=vs.80).a... It's tedious. R# does this with one shortcut -> Generate Code -> generate equality comparer and then it gives you a choice of which properties should be part of the equality comparison --- You need to quickly create an override of .ToString() maybe you just want something friendly during debugging. Say you have 10 properties. Again, that's Generate Code -> create formatting member. ---- Say your class has gotten to big and you see some methods that should be their own class. Refactor -> Extract class. And it will automatically create a reference to the extracted class ---- Say you have a base class and your inherited class has some members that should be in the base class or the interface. Refactor-> Move members up ---- You have a method that has too many members and you want to create an object that encapsulates your parameter list into an object. R# can do that for you and change all of your usages throughout your code base to use your new class. --- What if you decide to "prefer aggregation over inheritance" or you have a sealed class that can be inherited and you want to make it inheritable by doing a wrapper class. Generate Code -> Create delegating members. ---- Say you wrote a foreach loop and realized you needed a for loop: Alt-enter convert foreach to for --- Say you wrote some Linq code that would be clearer imperative -> there is a shortcut for that too. --- What if you really hate Microsoft's test runner and prefer Nunit -R# has got you covered. ---- This list doesn't include all of the other random niceties: -Fixing namespacing throughout your project with one click -suggesting coding standards -Ctrl-T for universal search -convert code to Linq expression -safe parameter removal -navigation shortcuts -warns of unused classes and is smart enough to know if you're using a class via convention based Dependency Injection (i.e. automatically use Foo when a constructor asks for IFoo) -Asp.net MVC has a lot of "stringly typed" conventions for specifying controllers and actions that will only give you runtime errors not compiled time errors R# is smart enough to know when you are using an invalid Controller/Action combination. -extract method, extract class, extract variable and the inline reverse of all of the above.
eropple 9y ago
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.
- k__ 9y ago
  > Kotlin is just Java! 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.
  - mixedCase 9y ago
    The JSX thing is because we (as an industry) teach "separate your concerns" as gospel and naturally you're going to get some pushback, specially from the very numerous group of "by the book" developers. Scala was treated for a long time as "a better Java"; but Kotlin really is way more befitting of the title. There shouldn't be as much resistance.
manquer 9y ago
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
mephitix 9y ago
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.
Entangled 9y ago
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.
- smichel17 9y ago
  Note that you can do functional Kotlin with the `tailrec` keyword for functions.
wazoox 9y ago
Well maybe, but the Steve Yegge wrote this: https://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better-than-whatever-dumb.html 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.
- clumsysmurf 9y ago
  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.
  - edem 9y ago
    Try it and you'll see.
- zem 9y ago
  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.
- eludwig 9y ago
  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!).
Zekio 9y ago
Hopefully most if not all of the points mentioned will become equal or better than Java as Kotlin matures
SonOfLilit 9y ago
Steve Yegge recently rose from the proverbial grave to build a case for Kotlin: https://steve-yegge.blogspot.co.il/2017/05/why-kotlin-is-better-than-whatever-dumb.html https://steve-yegge.blogspot.co.il/2017/05/why-kotlin-is-bet...
atemerev 9y ago
If this is not FUD, what is?
- edem 9y ago
  Dunno. This is definitely FUD and as such it is a waste of time to read.
- 35bge57dtjku 9y ago
  Why is it FUD? There seems to be a serious split here with lots of people loving the article and lots not.
  - edem 9y ago
    It tries to spread Fear, Uncertainty and Doubt, no?
watwut 9y ago
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.
utkarshsinha 9y ago
Did you remember other languages by Google? Dart anyone?
- klancaster 9y ago
  Google did not come up with this - JetBrains developed the language and use it to develop their tools.
xiaoma 9y ago
>"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.
- aembleton 9y ago
  I wonder if they make use of any other languages for other tools such as Spock, or if they get rejected because they are different.
- ramensea 9y ago
  It might be their size. I can say as a small team, the transition was seamless.
- strictfp 9y ago
  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)
  - Stratoscope 9y ago
    It's not just Java either. I worked with one OSX/iOS dev who knew Objective-C inside and out, but knew no other languages and didn't want to learn any others, because after all you can do anything in Objective-C. I asked him what he used if he just wanted to write a quick little script. "Objective-C." There's something to be said for his kind of mastery of a single language, but it was different from the multilingual culture I'm used to. I wonder if he's using Swift now...
  - 9y ago
AzzieElbab 9y ago
Never read a troll that ended with "we are hiring" before

142 points by PleaseHelpMe 9y ago

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.

edem 9y ago

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.

bsder 9y ago
> 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.
- edem 9y ago
  Not true. Our codebase is java/kotlin and it works.
gleenn 9y ago
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.

swsieber 9y ago

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.

scarface74 9y ago

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.

jmnicolas 9y ago
I'm curious to know what R# does for you (honest question). At work I use Visual Studio but I never felt the need for an addon, my needs are met.
- scarface74 9y ago
  I know this might come across as an infomercial. I'm really just a fanboy of JetBrains. To give even more context, I'm also a one handed typist (not by choice). So the various R# shortcuts really help me code faster. Some of my most used patterns 1. Create a class 2. Type ctor + tab - create a constructor (VS) 3. Type a parameter type and a variable (R# auto completes with a reasonable name) 4. Type Alt+Enter+Enter. R# creates a private class field and assigns the parameter to the private field ---- I need to create an equality operator for a class. This is the standard c# pattern: https://msdn.microsoft.com/ru-ru/library/ms173147(v=vs.80).aspx https://msdn.microsoft.com/ru-ru/library/ms173147(v=vs.80).a... It's tedious. R# does this with one shortcut -> Generate Code -> generate equality comparer and then it gives you a choice of which properties should be part of the equality comparison --- You need to quickly create an override of .ToString() maybe you just want something friendly during debugging. Say you have 10 properties. Again, that's Generate Code -> create formatting member. ---- Say your class has gotten to big and you see some methods that should be their own class. Refactor -> Extract class. And it will automatically create a reference to the extracted class ---- Say you have a base class and your inherited class has some members that should be in the base class or the interface. Refactor-> Move members up ---- You have a method that has too many members and you want to create an object that encapsulates your parameter list into an object. R# can do that for you and change all of your usages throughout your code base to use your new class. --- What if you decide to "prefer aggregation over inheritance" or you have a sealed class that can be inherited and you want to make it inheritable by doing a wrapper class. Generate Code -> Create delegating members. ---- Say you wrote a foreach loop and realized you needed a for loop: Alt-enter convert foreach to for --- Say you wrote some Linq code that would be clearer imperative -> there is a shortcut for that too. --- What if you really hate Microsoft's test runner and prefer Nunit -R# has got you covered. ---- This list doesn't include all of the other random niceties: -Fixing namespacing throughout your project with one click -suggesting coding standards -Ctrl-T for universal search -convert code to Linq expression -safe parameter removal -navigation shortcuts -warns of unused classes and is smart enough to know if you're using a class via convention based Dependency Injection (i.e. automatically use Foo when a constructor asks for IFoo) -Asp.net MVC has a lot of "stringly typed" conventions for specifying controllers and actions that will only give you runtime errors not compiled time errors R# is smart enough to know when you are using an invalid Controller/Action combination. -extract method, extract class, extract variable and the inline reverse of all of the above.

eropple 9y ago

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.

k__ 9y ago
> Kotlin is just Java! 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.
- mixedCase 9y ago
  The JSX thing is because we (as an industry) teach "separate your concerns" as gospel and naturally you're going to get some pushback, specially from the very numerous group of "by the book" developers. Scala was treated for a long time as "a better Java"; but Kotlin really is way more befitting of the title. There shouldn't be as much resistance.

manquer 9y ago

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

mephitix 9y ago

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.

Entangled 9y ago

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.

smichel17 9y ago
Note that you can do functional Kotlin with the `tailrec` keyword for functions.

wazoox 9y ago

Well maybe, but the Steve Yegge wrote this: https://steve-yegge.blogspot.fr/2017/05/why-kotlin-is-better-than-whatever-dumb.html 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.

clumsysmurf 9y ago
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.
- edem 9y ago
  Try it and you'll see.
zem 9y ago
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.
eludwig 9y ago
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!).

Zekio 9y ago

Hopefully most if not all of the points mentioned will become equal or better than Java as Kotlin matures

SonOfLilit 9y ago

Steve Yegge recently rose from the proverbial grave to build a case for Kotlin: https://steve-yegge.blogspot.co.il/2017/05/why-kotlin-is-better-than-whatever-dumb.html https://steve-yegge.blogspot.co.il/2017/05/why-kotlin-is-bet...

atemerev 9y ago

If this is not FUD, what is?

edem 9y ago
Dunno. This is definitely FUD and as such it is a waste of time to read.
35bge57dtjku 9y ago
Why is it FUD? There seems to be a serious split here with lots of people loving the article and lots not.
- edem 9y ago
  It tries to spread Fear, Uncertainty and Doubt, no?

watwut 9y ago

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.

utkarshsinha 9y ago

Did you remember other languages by Google? Dart anyone?

klancaster 9y ago
Google did not come up with this - JetBrains developed the language and use it to develop their tools.

xiaoma 9y ago

>"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.

aembleton 9y ago
I wonder if they make use of any other languages for other tools such as Spock, or if they get rejected because they are different.
ramensea 9y ago
It might be their size. I can say as a small team, the transition was seamless.
strictfp 9y ago
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)
- Stratoscope 9y ago
  It's not just Java either. I worked with one OSX/iOS dev who knew Objective-C inside and out, but knew no other languages and didn't want to learn any others, because after all you can do anything in Objective-C. I asked him what he used if he just wanted to write a quick little script. "Objective-C." There's something to be said for his kind of mastery of a single language, but it was different from the multilingual culture I'm used to. I wonder if he's using Swift now...
- 9y ago

AzzieElbab 9y ago

Never read a troll that ended with "we are hiring" before