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.
What trouble did you run into with JSON? I just make Jackson objects as data classes and I'm done with it. Mucking with ObjectNode/ArrayNode is a bit annoying but not too bad, especially when you can map and collect.
Was gonna say what you did about testing, but you have it, so, yeah. ;)
Short answer is the presence or absence of a field can drive us to different paths in the code base. That can lead to code littered with !! and @JsonIgnoreProperties(ignoreUnknown=true), or multiple intermediary data classes, or similar solutions. For much of our problem space, an extra val or two and some well placed ifs get us out of it.
> 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.
Does it? I really prefer JSON.NET's approach, which involves declaring models that represent your JSON, over dynamic "hope it's there" approaches.
False equivalence. You can static check this until you ate blue in the face but you still 'hope its there'. You would specify the contract for runtime checking like any sane engineer
Yes, but I don't have to worry about something like unintentionally spelling it differently on different lines, and in the case where I'm controlling both ends it is truly taken care of for me.
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 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.
I never considered Scala a better Java. Scala was attempting to be a better language on the JVM, but you'd have to be tripping on something seriously heavy to think Scala even remotely resembles Java. Scala was basically the unholy love child of OCaml, and Haskell, with a tiny sprinkle of Java on top to make it play nicer on the JVM. I had high hopes for Scala, I'm a huge fan of Haskell, but I just couldn't bring myself to like Scala, it's an ugly language that ruins everything good in Haskell by polluting it with OO.
Kotlin on the other hand, really is a better Java. If you take Java, remove all the biggest day to day headaches, change around the defaults to be sane (I.E. the default is what you want 90% of the time, instead of the other way around), and add in some functional inspired helpers, you basically arrive at Kotlin. The delegate system, the way they finally got rid of the need to make pointless getters and setters on the off chance you might some day want them and not want to refactor your entire codebase, making classes and methods public by default since that's what you want almost always, and making types non-nullable by default are all MAJOR improvements over Java, but not something completely alien to the Java way of doing things.
Anecdotally my experience is that for every one really good developer there's about 25 or 30 mediocre ones, and 5 or so really terrible ones. This is based mostly around what I've seen conducting interviews in my area. That is also highly variable, I did some interviews for another office (in another country) and saw ratios more like for every three good developers there were two mediocre ones, and no terrible ones. Maybe we just had a much better recruiter feeding us candidates in the other country, or maybe they just have exceptional programmers living there.
10000 lines might not be enough. I'm not sure that it's possible to determine whether something is a valid email address other than trying to send mail to it. If you haven't read the RFCs, they're pretty much a nightmare. The HTML5 spec has this little gem:
> This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.[0]
As an aside, if anyone has ever actually used comments, whitespace, or quoted strings in an email address, that would be be extremely interesting to hear about.
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.
I'd be very interested to see if this works out well in practice.
We had the same hope for Scala - the idea being that the developers who were interested in using it functionally could do so in the more complicated parts of our application, but the 'rest' of the developers, many who were honestly either not capable or just not interested in picking it up, would be able to still use traditional Java.
Unfortunately, Scala just had too many incompatibilities: things like Options instead of null or to call a Scala method in Java would require some confusing method call like
new Function0<String> because that is how Scala converts to bytecode.
And collections and immutable types never really worked back and forth very well.
The final straw was when we had Thrift interfaces that simply broke if a project moved from Scala 2.10 to 2.11 without recompiling all the dependencies.
But if Kotlin really is completely compatible with Java without too many show stoppers dragging down productivity, this could be helpful for a lot of larger enterprise shops which contain a small subset of engineers who want and can use the language to improve things (or simply don't want to work with old Java code and will jump ship if forced to do so), but still need to keep things simple enough so that the rest of the team can still be productive.
Kotlin is Java in a way that Scala isn't, so, yeah, it works a lot better. The edges can be a bit strange for the Java user but usually in positive ways--for example, passing a null parameter into a Kotlin method that does not accept a null parameter will cause an exception at the call site.
`val` in Kotlin creates an (inaccessible, except via reflection) backing field and a bean-compatible getter. `var` the same, but with a setter. Stuff like that. It works incredibly well.
I learnt Kotlin by taking an Android app which I had written in Java, and gradually converting it i to Kotlin, this was just after 1.0.
I'm a solo developer, and I use K and J together on most codebases (about 10), and at this point I only ever create K files.
Regarding interop, I think it's a valid claim that K is 100% J compatible.
I think instead of arbitrarily mixing the two, maybe start with a single module, or with testing.
I write a lot of JS, and have been planning on trying out Kotlin with JS, because at this point, taking a JS function and converting it to Kotlin results in code that's between 70-80% Kotlin (const to val, add return types, etc.)
I'm personally convinced that Kotlin is a good language to learn if you know Java.
By way of analogy I'll compare languages to languages, specifically spoken and programming. Going from Java to Kotlin is like going from French to Spanish. Going from Java to Scala, is like going from French to Klingon.
More concretely, Scala actually had very little in common with Java. Yes it ran on the JVM, but that was where the similarities stopped, its functional layer and type system were effectively incompatible with Java or the Java standard library. Actually Scala was so badly made, its functional pieces weren't even really compatible with its own OO pieces, if you tried to mix and match the two it caused all kinds of problems. Kotlin in contrast is almost entirely compatible with Java. There are a couple rough spots, mostly around when frameworks depend very heavily on reflection and bytecode manipulation (particularly around annotations), but those can be worked around from both sides without too much trouble, and the rest of the time it's pretty much completely transparent.
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.
Java itself is pretty big language. Each framework effectively forks it and makes another dialect, so the term is pretty loaded. Dropwizard, Spring, Guava, are all their own in thing in addition to Java. Then one has to learn to the domain and the codebase. Language itself is just a small portion of solving the problem.
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)
I just started using it recently and while writing in Babel/ES6 is nice, figuring out which framework or libraries to use (React vs Web Components and React vs Vue vs Polymer vs Angular vs...), sass or less, to redux or not, setting up webpack is definitely not an enjoyable experience. The beauty of many other languages is it doesn't usually involve so many decisions. There's usually an undisputed better library, a recommended setup, but js ecosystem now has so many options that it only leads to decision fatigue.
> The ecosystem around it sucks but the language itself is not too bad
The problem is that the ecosystem is what matters nowadays. A language can suck donkey balls and win as long as it has a robust ecosystem (see: VB6, PHP, etc.)
Python and Rust have phenomenal ecosystems. I have no clue about the C++ ecosystem nowadays.
The semantics is the major pain point. It doesn't flag many errors. Python is a much easier language to dev/debug in because of this. Also, if you're going to transpile, why not transpile from a nicer language? ES6 is competing with ClojureScript/TypeScript/etc.
True, but transcompiling hasn't been a very commonly used term for that so it's not an obvious term to use. For example, the early C++ compiler that targeted C was not referred to as a transcompiler. Nor was the popular f2c fortran-to-c compiler.
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.
Wow this really makes me grateful for the team I work on. This past 4 months we had to build some stuff that was off of our usual platform using Python and none of us had any real world experience with python, but we all buckled down and became quite proficient. None of us really complained (ok we did complain some about the import system but other than that we were good) and we were able ship a great first pass at the problem quickly. I guess curmudgeon devs are just curmudgeon devs.
Most of the code I've written in my career is JS/TS, with Java and Python probably tied for second. I'll admit to not liking Java but it's got nothing to do with not wanting to learn a new language. Most Java code is extremely verbose, with tons of boilerplate for doing simple things, like copying props from one object to another.
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.
The jump from Java to Kotlin is a lot less than the jump from C to C++. 75% of Kotlin is just syntactic sugar for things you are already familiar with in Java (things like defaulting to public access), so those are really easy to wrap your head around, and the remaining stuff isn't that far removed from what you're used to. Going from C to C++ on the other hand is introducing OO concepts, and then there's the STL which is basically an entire second functional language on top of C++.
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.
Yeah I'd be pretty pissed if I couldn't renew my license to Intellij this year because of some sanctions passed against Russia due to political BS by our political parties.
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.
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:
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.
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!).
I had the opposite experience - nearly a decade of Ruby and JavaScript, switched to Java and felt like I could finally breathe again! Not that it doesn't have its annoyances, but I sleep a lot better at night now. Kotlin (and TypeScript for that matter) seem like they cut out some annoyances while keeping everything that makes me breathe easier.
In case you haven't played with it, you may find that you like Groovy for writing Java in a JavaScripty fashion.
I have a ton of JS experience, and one thing that has continued to pain me with Java has been the arcane incantations required for Async and Closures.
I'd used Groovy just a little bit here and there for Jenkins stuff, but I finally looked into while building a DSL for our company. Closures are first class, typing is generally pretty optional, and you can use just about any Java library. When in doubt, you can always just write plain old Java.
I've become a huge fan, though I haven't started introducing any Groovy to my existing Java projects as they're mostly Maven built, and I don't really want to rock the boat.
Speaking of Kotlin and JetBrains, IntelliJ has pretty good support for Groovy, and follows @Delegate annotations very well for hinting and IntelliSense. I made my entire DSL type hintable with like four annotations and a 4 line GDSL file.
I'm curious what you mean here with the implication that you couldn't simply add Groovy code to your existing apps built with Maven. Have you tried it?
It has been probably over 5 years but when I was writing a lot of Java and Groovy, we were standardized on using Maven at that company. The Groovy Maven plugins worked and I had several projects with various mixtures of Groovy, all built with Maven: from Java with Groovy tests, to Groovy and Java throughout, to pure Groovy web services. It was a bit of a pain getting the configuration set up initially but it worked well.
It still works if you use the groovy-eclipse plugin in Maven, otherwise no. A lot of the Groovy interop tooling has fallen behind in 2017. For example, the developers I work with who use Eclipse could not run Spock tests because the plugins for 2.5 are busted. If you use IDEA you are still gtg.
What I didn't say was that my only experience so far is with Groovy by itself, and using Gradle to build. It's not an implication of Groovy or Maven for not supporting it, it's that I don't know the right way to do it yet.
I haven't used Maven in a long time and I'm not sure what is the state of the Groovy Maven plugin. Writing unit tests in Groovy for your Java projects is a great, low risk way to get things working.
Don't use Apache Groovy in typed mode -- hardly anyone else does, and you won't find any typed Groovy in its own codebase, only Java. Groovy was originally built as a JS-style dynamic language and is best used in untyped mode.
Fwiw, I use @CompileStatic it extensively and find it pretty good. There are the odd times when it generates a bizarre failure that I can't solve, but they are rare enough that I don't mind. I recently converted a whole project from Groovy to Scala hoping for performance benefits and found that my dynamic Groovy sprinkled with a few static compile hints ran faster than the Scala version. By the time I got the Scala version to the same speed as the Groovy version it looked a lot less like idiomatic Scala than the typed Groovy looked like idiomatic Groovy. So overall pretty happy with it, and I hope they keep improving it.
Most developers will use known code samples (e.g. Groovy's lack of statically compiled Groovy in it's own code base) rather than anonymous claims (e.g. you using @CompileStatic extensively) when deciding on a programming technology.
I think the difference is with typescript you can gradually type things or just us any when you don't want too. You get the best of both worlds IMO.
I'm more excited about using typescript def files in my JS code for third party libraries than I am using Typescript itself. What I really want is code completion and type hints
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
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.