7 ms·

Kotlin has been a joy to use. Really happy with it. Our Android app (http://play.google.com/store/apps/details?id=com.eatsa.app http://play.google.com/store/app

Kotlin has been a joy to use. Really happy with it. Our Android app (http://play.google.com/store/apps/details?id=com.eatsa.app http://play.google.com/store/apps/details?id=com.eatsa.app) is 100% Kotlin (with a good amount of Java libraries of course). 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.

brightball 10y ago
Even though I'll happily claim to being all aboard the Elixir train, I've looked at Kotlin due to so many of my Java friends talking about it. I really like everything I've seen from it. If/when I finally need to get around to learning to make an Android app it's definitely the first place I'll look.
salimmadjd 10y ago
My first thought was, a post to promote an app. But then, realize it's Eatsa so it probably doesn't need any promotion. 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
- gregschlom 10y ago
  Yeah, I only included the link as a proof that we're actually using Kotlin in production :) 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.
  - Nullabillity 10y ago
    Also, using it with RoboGuice is a bit annoying. 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.
    - gregschlom 10y ago
      Wouldn't a `lateinit var` solve the problem in this case? (Although the downside is that now it's a variable) Otherwise I'm sure you can come up with a good solution using delegated properties or something like that.
      - Nullabillity 10y ago
        Oh wow, wasn't aware that existed. Thanks!
    - BoorishBears 10y ago
      People still use RoboGuice?
    - deleted 10y ago
      [deleted]
dimascyriaco 10y ago
Is the iPhone app a completelly diferente codebase?
adrianlmm 10y ago
Why not use Xamarin? it has a better lenguaje (C#) and is free.
- on_and_off 10y ago
  C# better than java, maybe but than Kotlin ? That's a very subjective opinion. 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-xamarin-why 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)
- bitmapbrother 10y ago
  Probably because IntelliJ is a superior IDE, Kotlin is a better language than C# and Xamarin apps look and perform like ass.
  - V-2 10y ago
    I like both, but why do you consider Kotlin better than C#? 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.
    - voddan 10y ago
      iOS and Android UX guides have completely different approaches to the logic of user interaction. AFAIK, Xamarin does not allow to have different layouts generated from shared code. So, even that components are native, their placement is alien.
      - V-2 10y ago
        > Xamarin does not allow to have different layouts generated from shared code 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.

brightball 10y ago

Even though I'll happily claim to being all aboard the Elixir train, I've looked at Kotlin due to so many of my Java friends talking about it. I really like everything I've seen from it. If/when I finally need to get around to learning to make an Android app it's definitely the first place I'll look.

salimmadjd 10y ago

My first thought was, a post to promote an app. But then, realize it's Eatsa so it probably doesn't need any promotion. 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

gregschlom 10y ago
Yeah, I only included the link as a proof that we're actually using Kotlin in production :) 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.
- Nullabillity 10y ago
  Also, using it with RoboGuice is a bit annoying. 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.
  - gregschlom 10y ago
    Wouldn't a `lateinit var` solve the problem in this case? (Although the downside is that now it's a variable) Otherwise I'm sure you can come up with a good solution using delegated properties or something like that.
    - Nullabillity 10y ago
      Oh wow, wasn't aware that existed. Thanks!
  - BoorishBears 10y ago
    People still use RoboGuice?
  - deleted 10y ago
    [deleted]

dimascyriaco 10y ago

Is the iPhone app a completelly diferente codebase?

adrianlmm 10y ago

Why not use Xamarin? it has a better lenguaje (C#) and is free.

on_and_off 10y ago
C# better than java, maybe but than Kotlin ? That's a very subjective opinion. 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-xamarin-why 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)
bitmapbrother 10y ago
Probably because IntelliJ is a superior IDE, Kotlin is a better language than C# and Xamarin apps look and perform like ass.
- V-2 10y ago
  I like both, but why do you consider Kotlin better than C#? 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.
  - voddan 10y ago
    iOS and Android UX guides have completely different approaches to the logic of user interaction. AFAIK, Xamarin does not allow to have different layouts generated from shared code. So, even that components are native, their placement is alien.
    - V-2 10y ago
      > Xamarin does not allow to have different layouts generated from shared code 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.