Recently, a blog post entitled “The Case Against Kotlin” was published on Medium. The title could have been more descriptive, and I appreciate that it doesn’t tout Kotlin as rainbows and unicorns, but it did bring up a few points that I’d like to address.
The Learning Curve
Whenever I hear about learning curve as a consideration for using new technologies, I approach the argument with a bit of skepticism. As technologists we have to continue to learn and evolve in order to stay relevant. It’s the nature of the field, which is still innovating and changing at a rapid pace. It can, indeed, take time for teams to come up to speed on a new technology, but ultimately it’s critical for most people if they wish to have a long fulfilling tech career. Having spent some time in stodgy enterprise Java corporate environments, I recognize that the learning curve is often touted as a reason for not wanting to adopt new tools and languages.
In one egregious example I recall an enterprise architect’s recommendation for a team to use GWT instead of a more modern Javascript framework for a web project. The main reason cited was not because GWT offered better support for the product or provided a better way to implement product features; it was because they felt it was unrealistic to have the team learn a new toolset and language. This type of culture is unfortunately all too common in the enterprise Java community. The QT framework takes this even further. With QT, you can use C++ to create applications for iOS and Android, but you end up writing more lines of code. Maybe that feels safer for a C++ developer, but the reality is that most developers will need to learn a number of different programming languages throughout their career.
Even if they revert back to a language they’ve used before, it offers them new perspectives on how they write code. For example, I spent a number of years in enterprise Java before taking a detour into Ruby. When I started doing Android development, I wrote Java very differently from the way I did before I switched to Ruby. Then, once I discovered Kotlin, it was a no-brainer to change languages again, because I love Android but hate Java! Eventually, after doing some projects using Swift and Typescript, the Kotlin experience made these languages easier to learn. To be fair, if we were, in fact, talking about learning something like Haskell, the learning curve may have been much steeper, but in this instance, we’re talking about a language that was designed with Java developers in mind.
Build Time
This is a current problem with toolsets. In the short-term, you can throw hardware at the problem (if you haven’t already), but in the long-term, as Ryan stated, it will be optimized. It’s simply part of using a newer language.
Development Stability
Again, this is something that you always have issues with when using you adopt a newer tool. For that matter, from time to time, I see stability issues even with established tools. If you’re new to the language, some issues may not be readily apparent and could send you down a few rabbit holes. As more developers use the tool, more articles will be published, and tools will improve.
Static Analysis
While there is some improvement that needs to be made to this in Android Studio, it does highlight a larger issue with tools, and Java, in general. After I had spent a number of years doing enterprise Java development, I found myself getting very dependent on development tools. Many of my co-workers felt the same way. While the tools are great, I’ve seen them make mistakes, even with Java. When I switched to doing development in a dynamic language, I was forced to break away from that dependency, because some static analysis that is possible in languages like Java are just not possible in Ruby and Javascript. I’ve also seen Android Studio do some strange things when it automatically makes changes based on static analysis of Java code.
Better analysis is definitely possible in Kotlin, but even without that, you end up writing less lines of code. Less lines of code means less lines of code to review. Do automated tools make things easier on a big team? Absolutely! But, if humans have less code to parse, it’s probably not making an enormous difference.
Reversibility
Kotlin is one of the few languages I’ve seen with IDE integration which will automatically convert another language to it in a fairly seamless manner. If you’ve ever done any iOS development, you’ll know that there is no automatic code converter built into Xcode that will convert your Objective-C code to Swift. If you convert some code and don’t modify it, you can always use source control to get the original version back. That said, it’s best to understand the limitation and what you’re getting into.
Caveat Emptor
Why are you using the tool?
I could spend some time advocating for using newer tools, but you first need to understand why you are using them! I’ve seen teams cargo cult new tools and technologies without understanding why they are using them. Enterprise Java earned this reputation which is how FizzBuzzEnterpriseEdition was created. Though this project is, of course, a joke, anybody who’s worked on enterprise software has seen this. Some parts of Android were arguably influenced by the enterprise mindset. The long-time Google-recommended practice of using content providers for local database storage is one of those concepts that they are now moving away from.
Kotlin is going to be with us for a while
Although Kotlin doesn’t have as much traction as some other languages, the signs all point to it gaining popularity in the mobile space. Whether it gains popularity on the server side or in other domains is an open question, but Android development is driving its adoption. Why? First, it has first class support in Android Studio, thanks to JetBrains. Second, with its new features and the reduced code footprint, it does give you long-term productivity gains (each line of code is a liability to a project.) Third, even before it was officially endorsed by Google, it was really the only reliable alternative to Java for native development. Finally, it is officially supported by Google.
Having done native iOS development in Swift as well, my biggest complaint about Kotlin is that my Android programs are still larger than their iOS Swift counterparts. Some of that is due to the design of the Android framework, but it’s also because the language is not as big of a step forward as Swift was from Objective-C.
Conservative development is detrimental in native development
Are there times when it makes sense to be conservative with your platform? Absolutely! But, mobile is changing rapidly. Each year, a new version of Android is released. If your apps are being run by consumers, that means that each year more users will be upgrading to new versions of the OS, with new features that need to be implemented. Tools are coming out that make use more productive and we are refining how we organize our applications.
Blaze the trail, but be ready for a few bumps
Before you use any new tool, understand why you are using it. For most new applications, I tend to use a MVVM architecture with data binding, Java RX etc. While there might be a good reason to go with MVP, most projects that start this way today have more to do with developers not wanting to learn the tools around MVVM than with MVP actually being a better choice.
Sometimes there are instances where an older architecture/technology/tool/language might be more appropriate for technical reasons. For example, when people need to develop native platform code that is optimized on Android, they use C++, which makes sense. But most applications don’t need this kind of optimization in the same way that most Android applications really don’t need extra Java-based optimizations. Things will certainly be a bit rougher around the edges with a newer technology. At times it might even be a bit of a white knuckle experience!
As soon as you write a line of code, it becomes legacy code. The older the tools you use to create your code today, the older the code will look when someone has to maintain it in six months. If it’s majorly unstable, or there is some edge case that the technology is not covering today that is critical to your applications, then wait. But, if there are a workarounds, these growing pains are investments in the future. When Swift first came out, a lot of Objective-C developers scoffed their noses at the new language. Now Swift is far more popular than Objective-C. The same thing was true with Java and C++.
In conclusion: Are there some few risks associated with blazing a trail with Kotlin? Of course! But what happens if you decide to arrive later to the party? As an organization, it means that you’ll be playing catch-up with your team, and an individual developer, it also means that you’ll be playing catch-up with your skillset. Legacy technology can be just as much of a liability, and Kotlin, compared to other technology changes I have seen, is a pretty safe bet and has a much lower barrier to entry.
In our 
We also designed them to work with one of the two color displays. In the photo below we have a display with 48 rows of blue pixels and 16 of yellow.
Continuing our 
While these sensors work well, they are pretty expensive. To be fair, the AdaFruit sensor has great documentation and a voltage regulator that allows it to work with either 5 V or 3.3 V circuits, and they’re guaranteed first run sensors. With a Pi, we only need to support 3.3 volts, which is the operating voltage for the bare sensor. Luckily, there are less expensive options available on 
After the students shorted out their units, this was the first symptom they experienced.
First of, the only officially supported Pi is the Raspberry Pi 3. We’ve heard unconfirmed reports of it working on a Pi 2, but can conclusively confirm that it will not even boot on the Pi Zero! If you look at the diagram of a Pi 3, you’ll notice that the USB power port is for power only. While USB can be used for bi-directional data transfer, at this time, the USB ports on an Android Things Pi cannot be used for ADB sessions. Therefore you will need to get your device connected to a network via an Ethernet cable or Wi-Fi.
Luckily, you can use a 
First, what happens if some common biographical information about a author needs to be changed (for example, the author’s website)? With the current data structure, we’ll need to update every book that we have in the data store. This might be a reasonable trade off if we have 10 books, but what if we have 1,000 or 1,000,000 books? If we have a mobile application that writes directly to Firebase, this would clearly be data intensive and highly impractical. Secondly, if we attempt to retrieve a list of book titles and authors only, a query against the data store will also return a lot of unnecessary nested data (such as the publisher, publication date, etc.) Again, this can cause the application to have excessive data usage and slow down query times. One way to fix this would be to normalize the data.
But, what if you have an iOS and Android Client that also has the ability to edit the address for Pearson? More importantly, what if there are a few thousand book titles in your repository that were published by Pearson? This would, again, create two problems. First, a mobile client might have to update a lot of records. Second, it increases the chance for out of sync data, since two codebases need to stay in sync with the updated data structure.
If you have a simple data structure, it will handle a lot of the data sync and caching for you, and create a very robust back end that can deal with a lot of traffic. If you have a complex data structure or a lot of sophisticated authorization rules, things may not be as cut and dry. There are a lot of benefits to using it, and in our opinion, they often tip the scales in favor of Firebase. That said, there might be other compelling reasons, such as a desire to version your API, increase security, or integrate with other platforms, where it would be more advantageous to create a custom API on your own server instance.
