Live data from Hacker News

Swift Ported to Android

github.com

141–150 of 153 posts

Re: Swift Ported to Android

#141
post #133

Earlier quoted context omitted.

Aren't these "performance gains" a wash due to the overhead of ARC?

Not really, reference counting is generally considered to be more performant than GC. GC can end up thrashing the cache and doesn't work very well when using more than 8 to 16 GB of RAM. Even the linux kernel uses reference counting as you need a rc / gc system to solve some problems. ARC just inserts the retain/release calls that you'd make anyway, pretty much everyone agrees that there are very few degenerate cases…

I came across this explanation on StackExchange on the performance penalties with ARC:

>As for performance both have performance penalties. Automatic reference counting delivers a more consistent performance, no pauses, but slows down your application as a whole as every assignment of an object to a variable, every deallocation of an object, etc, will need an associated incrementation/decrementation of the reference counter, and taking care of reassigning the weak references and calling each destructor of each object being deallocated. GC does not have the performance penalty of ARC when dealing with object references however it incurs pauses while it is collecting garbage (rendering unusable for real-time processing systems) and requires a large memory space in order for it to function effectively such that it is not forced to run, thus pausing execution, too often.

>As you can see both have their own advantages and disadvantages, there is no clear cut ARC is better or GC is better, both are compromises.

>PS: ARC also becomes problematic when objects are shared across multiple threads requiring atomic incrementation/decrementation of the reference counter, which itself presents a whole new array of complexities and problems.

Re: Swift Ported to Android

#142
post #125
post #75

Earlier quoted context omitted.

Guess what. No one cares if you don't use Swift. Go with Kotlin. It's probably a great choice for you. It seems like a great language and I hope it gains traction. You're doing that nerd thing where you need to tell the world why something isn't good for you. We'd waste a lot less time if we simply found the group we desired and added value there rather than find another group and tell them why what they're doing doe…

He's saying that Kotlin is similar enough to Swift, but integrates far easier with the Android ecosystem and development environment, such that it's probably a better choice for a lot of people wanting to make Android apps with a modern "swift-like" language. I think that's pretty relevant. You're doing that nerd thing where you're assuming we're divided into groups based on the technology we're using. We'd waste a l…

If all you're doing is Android programming Kotlin is probably a better choice at this time. If you're a Java programmer, Kotlin is probably a better choice. If you're already a Swift programmer...

Also, let's see how both languages gain traction in the next 3-5 years.

Re: Swift Ported to Android

#143
post #35

Earlier quoted context omitted.

No, for example UNIX IPC isn't available. Google has ripped most of the stuff they see as fluff for Android. Edit: Any C and C++ API not listed as stable and public on the NDK docs is not guaranteed to exist in all devices.

Google has ripped out most of the stuff that would have made smart phones actual computers rather than smart terminals.

If you think of C and C++ point of view, yes.

On the other hand the Frameworks are quite expressive for applications, but one needs to use Java 6.5 or resort to third party solutions like retrolambda and Kotlin.

Re: Swift Ported to Android

#144

Earlier quoted context omitted.

What's the canonical way of targeting Android with C++?

Write shared logic in C++ and use JNI/JNA ? Or are you asking about something more specific ?

I guess I found what I was asking about, i.e. NDK: http://developer.android.com/ndk/index.html

Re: Swift Ported to Android

#145
post #115

Earlier quoted context omitted.

I'm not sure about how mainstream/supported C++ is in the Android world.

Just as much as everywhere else, we're using it extensively for sharing code. If has a few qurks but it's easy better than windows for example.

Are you using NDK? I was reading about it earlier, it is something that I would like to look into, when I have some time.

Re: Swift Ported to Android

#146
post #128

Earlier quoted context omitted.

? Android apps are also compiled ahead of time right now (whether they are written in java or kotlin).

Don't you still have GC issues for heap allocation/destruction? Swift uses the ARC pattern so no GC lockups or performance issues. [1] https://developer.apple.com/library/ios/documentation/Swift/...

I have spent a large amount of time optimizing Android apps and GC pauses are generally not the issue (as long as you don't do something stupid like allocating objects in draw calls).

I think that ARC is probably an overall better solution but as far as GC pauses are concerned, we have reached the point where they don't impact performances.

Re: Swift Ported to Android

#147
post #115

Earlier quoted context omitted.

Just as much as everywhere else, we're using it extensively for sharing code. If has a few qurks but it's easy better than windows for example.

Are you using NDK? I was reading about it earlier, it is something that I would like to look into, when I have some time.

Yes, NDK is after all just a name for preconfigured GCC and Clang package shipped by Google :)

We use Clang 3.5.

Re: Swift Ported to Android

#148
post #136

Earlier quoted context omitted.

>but being able to develop libraries in one language and use them in both Android and iOS is huge I have no doubt that there are mobile only apps that would find this valuable - but swift is still only linux/android and osx/ios - if you want truly portable code - that can compile to browser/mobile/server/desktop you're stuck with C++ for the foreseeable future.

I've tried Haxe, Racket, TCL/tk, MOAI (Lua based), and others, but I am now using 8th, a Forth-like language that compiles to Android, iOS, Windows, OSX and Linux [1]. The only downside is that I still need a Mac to publish iOS apps. For Android, Windows and Linux, I am good to go. It uses the JUCE library for gui implementation. I have made two toy apps for Android so far, and I am still learning. It has a good libr…

What a strange beast! A closed source language is always a tricky sell. Forth is never an easy sell in itself (unless you've already been bitten by the bug ;-) in which case it's a wonderful bonus). The tutorial is PDF only - which just seems a bit odd.

I'm intrigued by 8th - in a good way - and happy you've introduced me to it - but I do wonder what kind of uptake something like this will get.

Re: Swift Ported to Android

#149
post #133

Earlier quoted context omitted.

Not really, reference counting is generally considered to be more performant than GC. GC can end up thrashing the cache and doesn't work very well when using more than 8 to 16 GB of RAM. Even the linux kernel uses reference counting as you need a rc / gc system to solve some problems. ARC just inserts the retain/release calls that you'd make anyway, pretty much everyone agrees that there are very few degenerate cases…

I came across this explanation on StackExchange on the performance penalties with ARC: >As for performance both have performance penalties. Automatic reference counting delivers a more consistent performance, no pauses, but slows down your application as a whole as every assignment of an object to a variable, every deallocation of an object, etc, will need an associated incrementation/decrementation of the reference…

[deleted]

Re: Swift Ported to Android

#150

Earlier quoted context omitted.

>friction between system libraries and your languages standard library Well, that's the thing : Kotlin emits bytecode. It is entirely interoperable with Java. All the Java APIs of the platform are accessible in Kotlin. Swift on the other end can only target the NDK, which limits it to a very specific niche on Android.

Just because they are accessible, doesn't mean using them is seamless. For example all of Objective-C's runtime and classes are available to Swift but there is some friction e.g. methods that emit untyped NSArrays rather than typesafe swift arrays, or cases where you have to avoid using Swift structs because they can't be passed into the Objective-C runtime. Apple's done a lot of hard work, and each release of Swift…

So far, it seems pretty seamless. I guess that with a couple of years working on a production app in Kotlin, I would have to discover some hairy corner cases though.

What helps a lot is that the kotlin team has written many helper methods allowing a better flow between the android API and kotlin code : while you don't need it in order to get interop, it allows to more easily write idiomatic kotlin code while interacting with Android.

Post reply on HN