41–50 of 114 posts
Earlier quoted context omitted.
That's putting the cart before the horse. Google's already shown with the Dart project that they're willing to invest in building tools for their own technology. Android Studio hasn't been the official Android IDE for very long either.
Since it's not 1.0, one could argue it's not even the official Android IDE yet.
Earlier quoted context omitted.
It's not only about Android. Kotlin is one of the few languages that's developed hand in hand with IDE support. That means you've got Java-class IDEA support for the language, including (interestingly) a Java to Kotlin converter tool! It's not like many languages where you end up having to sacrifice all your nice refactoring tools and libraries to use it. For this reason alone Kotlin is a natural upgrade path for man…
By the way, this converter is not without flaws. Eg. if you convert an Activity written in Java to Kotlin, method signatures do not match (because in Kotlin it should be Bundle? instead of Bundle and so on, since they are all nullable), and that results in baffling error messages that you're trying to override non-existent methods, it's not easy to figure out what's wrong.
Earlier quoted context omitted.
Minor correction. We don't make Android Studio. Android Studio is based off of the IntelliJ IDEA platform, which is what we develop.
Oh, thanks for the correction. I had assumed that JetBrain develops Android Studio and Google just puts their stamp on it.
Does anyone have some performance comparison betweend projects written in pure Java vs straightforward Kotlin? I don't feel that method count is performance measure, I'd rather see some fps, method calls/sec or something like this. Or I'm wrong about method count?
Kotlin is a much more pragmatic language than many such new ones. They are building it for use in their own products including performance sensitive products like IntelliJ. For example it has an inline method attribute. This may seem remarkably low level for a modern JVM based language intended for industrial use, but there's a point to it: it lets you use lambda functions and misc features that rely on them without extraneous memory allocations. Applied consistently this sort of thing can make the difference between "a lovely language that's too expensive to use" and "a lovely language that is deployable". It's not auto-inferred because otherwise you wouldn't be able to make libraries that have stable ABIs with Kotlin.
Generally they seem to be targeting zero performance degradation over Java even when using the advanced features, which is nice to see.
Earlier quoted context omitted.
Oh, thanks for the correction. I had assumed that JetBrain develops Android Studio and Google just puts their stamp on it.
Well that pretty much is what happens. JetBrains wrote IDEA and the Android support for it. Google made some small modifications (some good, some detrimental), and packaged it with the Android SDK. The biggest change was to switch to gradle which is a more powerful build system but also much buggier (at least in the current Android Studio). They also lots of useful Android-related tools and lints, and a fair helping…
It would be nice if more of this was folded into Java itself, rather than existing as a new language - as the author notes a lot of it is in Java 8.
also java 8 doesn't have eatures like string interpolation, default params, etc.
I've been looking a lot at Scala and kotlin recently. Other differences aside, Kotlin has an 800kb runtime compared to Scala 2.11's 11mb runtime. That's quite a difference
How do you come up with 11 MB? Even the whole library jar file which is much more than just the runtime is only 5.5 MB. But even then it doesn't matter anyway. Android apps are ProGuarded before deployment (regardless of the language used) and the overhead in Sclaa's case is a few dozen kBs.
With a 11 MB dependency, even production builds take considerably more time to complete and that gets in the way when you want to test the app on a production setting and you have to wade through a lengthy build process each time you fix a bug.