Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin, the Swift of Android

blog.gouline.net

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Kotlin, the Swift of Android

#101

Post by mh- »

michaelcampbell wrote: post #14
masklinn wrote: post #9

Earlier quoted context omitted.

It's way more fucked up than that, Dalvik is limited to 65k invocable methods per dex file: https://medium.com/@rotxed/dex-skys-the-limit-no-65k-methods... > You can reference a very large number of methods in a DEX file, but you can only invoke the first 65536, because that’s all the room you have in the method invocation instruction. > […] the limitation is on the number of methods referenced, not the number of met…

Is this limitation going away (or otherwise obviated) by ART?

the article linked in parent addresses that directly:

> And yes, you got it right. This issue won’t disappear even when Android will switch to the new ART runtime, unless Google decides to “fix” the DEX format or ditch it for another one.

Re: Kotlin, the Swift of Android

#102

Post by seanmcdirmid »

tkubacki wrote: post #70
seanmcdirmid wrote: post #67

Earlier quoted context omitted.

Dart supports shared memory multi threading?

DART has Erlang style actors that support concurrent threads of execution - so yes. Shared memory no AFAIK, but Dart seems to have nicer syntax.

If dart doesn't support ordinary threads, it might be meant for the web and not as a language for writing android apps.

Re: Kotlin, the Swift of Android

#103

Post by nine_k »

vorg wrote: post #98
gruvector wrote: post #81

Earlier quoted context omitted.

Go is pretty low level compared to (even) java, not much of a win in terms of expressiveness or error handling. Seems like a lot of effort with minimal benefit.

> Go is pretty low level compared to (even) java I've found Go and Java to be at the same level of abstraction. Go has interfaces and structs, but leaves out implementation inheritance because its authors feel that's one of Java's bad points. Go also leaves out method overloading which causes us to think hard about what to name the numerous methods. I don't know about the suitability of Go for Android though. Does Go…

Not so secret. Go's 5g compiler can produce ARM code, runnable on an Android device. But Android's APIs are mostly Java, so for regular apps you have little benefit in using Go; for games, you could gain something.

See a small overview: http://www.infoq.com/news/2014/06/golang-google-android-nati...

A JVM-compatible language which is better than Java, e.g. Kotlin, would be a boon for regular Android development.

Re: Kotlin, the Swift of Android

#104

Post by myko »

masklinn wrote: post #77
myko wrote: post #27

Earlier quoted context omitted.

Yes, but not just yet: https://plus.google.com/107130354111162483072/posts/VEy3JChn... Mentioned at about 27:55 in this podcast where a member of the ART team is interviewed: http://androidbackstage.blogspot.se/2014/08/android-develope...

You're talking about a similar but different issue: there's a fixed-size meta-information buffer, if you go above you crash. Increase the size of the buffer and you're good to go (which is what more recent android versions have done), the new ART might make the buffer dynamic instead of static (no idea). The 65k method problem is a problem of the dex format itself, because method-invocation instructions take "the met…

I think you are mistaken - in the audio: http://storage.googleapis.com/androiddevelopers/android_deve...

Around 27:55 they discuss that they plan on lifting the limit. Indeed modifying the dex format is talked about and it is mentioned that it is a future goal.

They also speak about multidex, the interim backwards compatible fix which does not require modifying the dex format (but uses a hack) and will make modifying the dex format easier in the future.

Re: Kotlin, the Swift of Android

#106

Post by masklinn »

myko wrote: post #104
masklinn wrote: post #77

Earlier quoted context omitted.

You're talking about a similar but different issue: there's a fixed-size meta-information buffer, if you go above you crash. Increase the size of the buffer and you're good to go (which is what more recent android versions have done), the new ART might make the buffer dynamic instead of static (no idea). The 65k method problem is a problem of the dex format itself, because method-invocation instructions take "the met…

I think you are mistaken - in the audio: http://storage.googleapis.com/androiddevelopers/android_deve... Around 27:55 they discuss that they plan on lifting the limit. Indeed modifying the dex format is talked about and it is mentioned that it is a future goal. They also speak about multidex, the interim backwards compatible fix which does not require modifying the dex format (but uses a hack) and will make modifying…

> I think you are mistaken

The question was whether ART would fix the issue. The answer is not "yes but not yet", it's "no" because the runtime has no bearing on the issue.

Re: Kotlin, the Swift of Android

#107

Post by hellrich »

hhariri wrote: post #78
aikah wrote: post #76

Any reason to use this over Groovy ? Will Groovy has a few drawbacks, i found it much simpler and easier to use than scala.I personnally prefer a quick java over something that has to much features.Anybody tried both and can compare?

One reason would be if you prefer static typing.

In recent Groovy versions you can have type checking or even static compilation by annotating your code.

Re: Kotlin, the Swift of Android

#108

Post by richardwhiuk »

gruvector wrote: post #82
richardwhiuk wrote: post #10

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.

If you 'folded' Kotlin into Java what would you gain over just using Kotlin?

Interop with existing code, access to a large developer, infrastructure and mindshare - especially in enterprise where take up of new languages is more considered?

Re: Kotlin, the Swift of Android

#109

Post by eeperson »

V-2 wrote: post #37
eeperson wrote: post #12

Earlier quoted context omitted.

Have you looked at the usage guides for the various plugins [1][2]? [1] https://github.com/jberkel/android-plugin/wiki/getting-start... [2] https://github.com/pfn/android-sdk-plugin#usage

I can't remember anymore what I tried and what I didn't :) At the end, I mostly tried not to bang my head against the wall. Anyway, even your second link stresses: "The primary IDE recommendation is IntelliJ, not Android Studio nor Eclipse". My IDE of choice is Android Studio, and it not being particularly recommended is a red light to me already. Maybe I'm just traumatized. I'm surely lazy. I wish Google made Scala…

That recommendations is strange. The directions just have you include an almost standard version of the IntelliJ plugin for SBT (it is the standard plugin with an extra bug fix). So, any of these IDEs should work without issue. You just need to set up the standard SBT plugins for integrating those IDEs.

Re: Kotlin, the Swift of Android

#110

Post by on_and_off »

vorg wrote: post #98
gruvector wrote: post #81

Earlier quoted context omitted.

Go is pretty low level compared to (even) java, not much of a win in terms of expressiveness or error handling. Seems like a lot of effort with minimal benefit.

> Go is pretty low level compared to (even) java I've found Go and Java to be at the same level of abstraction. Go has interfaces and structs, but leaves out implementation inheritance because its authors feel that's one of Java's bad points. Go also leaves out method overloading which causes us to think hard about what to name the numerous methods. I don't know about the suitability of Go for Android though. Does Go…

Officially, Java is the language of Android. Have a look at the last I/O fireside chat if you want to hear from them. Again, officially, they "don't see what rewriting all the API in another language would bring". Google is deeply involved in improving Java with projects like Guava, Dagger, ..

There is a project to make Go run on Android, but it is only a hobby project from one of the Go engineers and only target the NDK (so no access to Android's APIs).

We have no way to know what they are working on under the covers, we need to assume that as far as we know, Java is here to stay... IMHO, with Dagger, Guava, EventBus and a couple other niceties, it is possible to be productive with Android. For me the biggest weakness of the platform from a dev point of view is that many things that are part of the platform on iOS (like elements of a ListView animating themselves when added/removed) need to be coded (with dirty and lengthy hacks). This part is improving (I am looking at you RecyclerView & RenderThread) but there is still a lot of ground to cover.

Post reply on HN