Kotlin vs. Java – An Android Developer's First Impressions | Hacker News Reader

Kotlin vs. Java – An Android Developer's First Impressions

arctouch.com

41 pointsreinecka21 comments

I've used Java very little. But about 1-2 years ago, on a long trip, and after learning about Kotlin on Android (iOS developer here) I decided to create a prototype of our iOS app on Android using Kotlin. Apart from some weirdness on the Android API (which Java, Kotlin, Groovy, etc) don't fix, I found myself very productive and created a fun prototype over a 14 hour flight that got me the OK to develop the first version of our Android app.

If you have developed in Swift (and probably other languages), Kotlin will feel very similar, the only thing you need to do is learn the native API's, but logic/model code is so similar you can just copy paste from swift->kotlin and vice versa and just fix 2-3 syntax issues

Not to sound disparaging, but could this basically be summed up as "Kotlin is the syntactic sugar version of Java"?

I mean, ignoring functional stuff which is in Java 8 but not on Android because Android is still(?) on Java 7, that's all I'm really seeing here.

Android actually now has some Java 8 feature support out-of-the-box [0] though most are API 24+.

After porting our code base to Kotlin we found it provides more benefits over Java than just being less typing / "syntactic sugar". To name a few:

  - First class functional support (streams feel clunky in comparison).
  - Extension functions [1].
  - Nullable types (compile-time null checking).
  - Less verbose as types declarations are optional in many situations.
  - Great interop & tooling from JetBrains makes a slow transition from Java -> Kotlin pretty seamless.

[0] https://developer.android.com/studio/preview/features/java8-...

[1] https://kotlinlang.org/docs/reference/extensions.html

Were the downsides manageable? Increase in APK size / build time?

As of Android 7, the following Java 8 language features are supported:

  Default and static interface methods  
  Lambda expressions  
  Repeatable annotations  
  Method References  
  Type Annotations

There's a bunch of stuff the article doesn't get into, specifically Kotlin's type system which is Java-like but not quite Java's.

Huh. Okay. I'll have to read more about that then.

Having used Java for 7 years, and using Kotlin for the past year, I would say it's the syntactic sugar version of java in the way that Java is the syntactic sugar version of C++, which is the syntactic sugar version of C which is the syntactic sugar version of ASM, etc...

So what am I missing? Or rather, what is the article missing? (I knew nothing about Kotlin before this article)

I mean, I wouldn't agree with the classification of any of those languages as the syntactic sugar of whatever. C is portable ASM, which is a big deal. C++ is object oriented C, which is a different paradigm and feels a lot more salty than C because of the increased complexity. Java was rather ambitious (safe to say overly so) and brought with it a lot of differences with C++ that were not just syntax (which is definitely sweeter).

What does Kotlin give me besides less verbose syntax and some nice compile time null checking?

Perhaps a little off-topic, but can anyone share their experience with using Kotlin to build a non-trivial web app and what their stack was?

I work at one of those big tech companies which has a huge number of services in its codebase in Java (you could properly guess the company). We use Kotlin daily for back-end services as a cleaner and more powerful Java, and we've migrated most of our original Java spring/rest projects to be in Kotlin. If you're familiar with Java-based stacks, I think it's fairly trivial to migrate to Kotlin first as a Java substitute before taking advantage of everything Kotlin has to offer, then slowly adopting Kotlin principles.

I am really interested in what company this is. I love kotlin and wish I could switch all of our new java services to kotlin going forward

That's very encouraging to hear. Is your team still using it with Spring (Spring Boot?) or something along those lines? If you were starting a new Kotlin REST server app today, do you think your team would still use that?

I use Kotlin for services I write. My previous stack was Kotlin + Vert.x but I've ditched Vert.x for Sparkjava more recently... not a fan of the async model.

Async is fine but Vert.x's version of it is kind of retarded. Callback hell. Might be better with 3.4 now that it supports Scala and Futures.

Yes, I think you're right. The Vert.x model is "weird" to put it politely. Too many callbacks, but also I felt like much of my domain and business code was being "infected" by Vert.x machinery as I tried to make my code async friendly.

It makes a lot of big promises, delivers on many of them early on but as your services grow things... get messier.

Happy enough with Sparkjava right now. I think ultimately though I'm on a slow journey back to just using Dropwizard which still hits the sweet spot for me.

I'd probably be more willing to dive in with Kotlin if there were a reliable way of translating back to passable Java. In other words, an escape hatch in case it doesn't work out, or the use of a not-Java language causes too much trouble with other employees down the road.

I'm not sure how feasible that is but many features seem to have fairly direct translations. For others like co-routines I'd be willing to put up with the Java project depending on a Kotlin runtime jar.

Off-topic but is anyone else unable to scroll on this page?

Works for me.

Whenever you have such a complaint - and choose to make it public - please include more details. What system, what browser, add-ons (adblocker) at least.

EDIT: Downvotes? For answering the question truthfully? It does work for me. The question was (is) "is anyone else unable to scroll on this page?" -- and I have no problem scrolling. I answered the question! The question was NOT "do you think the page is designed badly". If that is what was meant, that is why I said "needs more details". All the person asked was about "being able to scroll"! And the design issue does not prevent it. I answered the question that was actually asked! I assumed, and still do, that the person isn't able to scroll at all.

It's got odd scrolling. If the mouse is over the top banner, and you scroll the scroll wheel (or I assume pull down on mobile?) then the page doesn't scroll (this is on Chrome, on Windows 10).

The scrollbar is also hidden behind the top banner in some way, which suggests it's doing something non standard.

Why do people want to fiddle with the most basic UI/X idiom on the net?

There doesn't seem to be a lot of critical thinking done by developers at times.

They'll read a blog post, echo chamber the benefits over some kale juice and start hacking away.

Reply on news.ycombinator.com