4 ms·
Why would I ever care about Go for Android when I can write apps in Kotlin? Kotlin is fully interoperable with Java. I don't have much experience with Swift b
by jophde 11y ago
Why would I ever care about Go for Android when I can write apps in Kotlin? Kotlin is fully interoperable with Java. I don't have much experience with Swift but Kotlin is so nice. It has the best features from numerous languages such as Ruby. C#, etc. It's being made by Jetbrains who makes the the core of Android Studio so it will have support. Kotlin is also nearly as fast at runtime as Java with a tiny 200kb runtime. Almost all the magic happens at build time so your build time will be a little longer. Kotlin also works with any existing Java library, even annotation processing libs.
Again, why would any Android developer choose Swift? Kotlin also runs fine on the server and it even compiles to Javascript.
If I were a startup doing an iOS, Android, and a backend I would do either Go or Rust on the backend. You will be able to distribute a native lib with your Android or iOS that shares network and model logic. Go and Rust both are planning on supporting cross compilation to iOS and Android.
That would leave you with Kotlin/Groovy/Clojure/Scala for the view layer of your Android app if you choose not use Java. Which is a good idea since there is no indication from Google Java 8 will be supported which means no lambdas unless you use an alt JVM language. On iOS you write your view layer in Swift. Both apps use the shared binary library.
- deleted 11y ago[deleted]
- edko 11y agoIf you use Scala for your view layer, why would you even want to use Go for your back end?
- jophde 11y agoVery true. I am starting to not see the point of Go. It's about the same performance as the JVM languages and the JVM is just as easy to deploy. On the JVM you get to choose between Clojure, Scala, Ruby, Groovy, Kotlin, and more. JVM is just as easy to deploy as a Go binary too. Personally, I plan to stick with JVM languages plus Rust.
- dschiptsov 11y agoHere is how to see the point of Go: Open the rosettacode web site. Choice any algorithm you are familiar with. Place Go version and Java version. Compare the number of words and lines. Compare the Maven hell with how Go solves the same problems.
- dragonwriter 11y agoSo, a more succinct Java, that can't leverage the JVM ecosystem? Why is that better than Scala, which can also be more succinct than Java, but can leverage the JVM ecosystem?
- randallsquared 11y agoGo is enormously simpler than Scala. (I also don't agree that the deployment story for the JVM and Go are similarly complex, but that's a different argument).
- jophde 11y agoI bet my Clojure or Groovy version will be simpler. I agree Scala is super complex :). Maven does suck. Gradle wraps it and does not suck. Probably the best build tool I have ever seen.
- Tloewald 11y ago> Why would I ever care about Go for Android when I can write apps in Kotlin Power consumption.
- eggy 11y agoI found this comparison between Swift and Kotlin interesting, and the point that it would make switching between Android and iOS development easier: http://blog.translusion.com/posts/swift-is-kotlin/ http://blog.translusion.com/posts/swift-is-kotlin/
- V-2 11y agoKotlin is positively awesome, but when I tried it (admittedly last year) it didn't seem ready for production yet. It worked all well as long as stuff was kept simple, then I used Realm.io, wrote some unit tests and got all sorts of NoClassDefFoundError exceptions, dexmaker errors etc. Long story short, I couldn't fix it. As I said, it's been a while. I hope things have been improving and continue to improve. The language itself is superb
- jophde 11y agoIt's pretty damn closed to 1.0. They just released M12 which adds support for interop with Java libs that use annotation processing such as Dagger.
- brmunk 11y agoWith the just released support for annotation processing Kotlin is now working with e.g. Realm.
- ufmace 11y agoI've just been playing with it some in the last couple of weeks. I get the impression that they're still iterating pretty rapidly on it - at least partly because the official practice repo uses trait all over the place, which they apparently deprecated and changed to interface. I will say that it It looks very promising so far, and seems to have the best of C# and Ruby, assuming you're sticking with compile-time type checking, plus a few more tricks besides. I'm not that up on JVM languages though, so I'm not sure that it's definitively better than any of the other choices.