What I like to know is the following:
What are some of the challenging issues of using Kotlin?
Did you start from Kotlin or migrated from java to Kotlin?
What drove the decision to use Kotlin in such a visible app?
What are the top 3 - 5 improvements or things you want to see?
Thanks
1. Kotlin issues:
- Libraries that use reflection (such as Gson) can break some assumptions that Kotlin makes (for example, a read-only field may actually change). There's maybe 2 or 3 little things like that that may catch you by surprise, but once you figure them out it's easy to work around them.
- Stack traces in lambdas are obscure sometimes. Sometimes you won't get the line number.
- Proguard integration has proven challenging.
2. We started from Kotlin.
3. Learning Clojure and Haskell has made me yearn for more functional languages and better type systems. Kotlin has that, in a neat syntax that's very beginners friendly.
I'm firmly convinced that a good programming language needs:
- Strong library ecosystem
- Static type system + type inference. (I won't get into the static/dynamic argument here. Suffice to say that there's a whole class of bugs that you can avoid with static typing, and type inference makes the "but I hate these types cluttering my code" argument irrelevant)
- Killer IDE support (essential for productivity. If you're writing a large application without using an IDE that gives you code inspection and navigation, you're wasting your time)
Kotlin has these 3 things.
4. Top improvement: can't wait for Kotlin 1.1 to be released, and start using coroutines. Other than that, I'm happy with it.
At the moment I use vals, but it still requires me to mark injected dependencies as nullable (and coerce them with !! on use), which feels like I'm fighting the type system.
It would be really nice if there was some sort of "special" null that was of the non-nullable type, but could only be used when initializing variables.
Otherwise I'm sure you can come up with a good solution using delegated properties or something like that.
If/when I finally need to get around to learning to make an Android app it's definitely the first place I'll look.
Apps written in Xamarin and kotlin work very differently :
-with Xamarin you have to add the Xamarin runtine and depend on its integration. This brings several downsides : http://www.slideshare.net/KonstantinLoginov/we-are-ditching-...
-Kotlin outputs bytecode, so from the outside, it is just the same as any android app written in java. The output is a standard android app with one more library (the standard kotlin lib with all its base methods)
I also don't get your point about how lame Xamarin apps look. Xamarin apps use native layout components (could be wrapped with lowest common denominator abstractions in case of Xamarin.Forms, but it's optional), so they're 100% capable of looking the same way your native app would.
That's true, but noone says or recommends that all the code is shared. Typical Xamarin architecture and good practice assumes sharing the business (or domain) layer, and coding the views separately. In terms of reusability it's still superior in comparison to writing both versions natively. Obviously the level of reuse you can achieve that way very much depends on the nature of the application.
Some highlights:
- Great type system, with type inference.
- Full Java interop. You can literally copy/paste Java code from Stackoverflow and it's automatically translated to Kotlin. It doesn't feel like 2 different languages. Working with Java libraries doesn't feel awkward or foreign, like in many other JVM languages.
- Beautiful syntax that allows to construct some pretty advanced DSL, yet because it's statically typed the IDE can always resolve the DSL constructs and take you "under the hood" to the actual code that's going to be executed. This is in contrast to languages such as Ruby where most of the time when you encounter a DSL construct there's no easy way to understand what's going on.