YellowBox was going to be a cross-platform updated version of the OpenStep APIs. While I remember some alphas of it, it basically got nixed.
http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F7...
As much as I enjoy using Apple products, their history says that they would not directly support something like this.
https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-libdispatch
Works is well under way.
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.
[1] http://8th-dev.com/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.
By that time Rust will also mature enough and webasm will land so Rust will probably be a better candidate (since it's OSS and developed by a browser company that needs to run on as many platforms as possible they have much better incentives to maintain ports than Apple).
Also in that time C++ will probably get modules working on clang and many c++17 features.
And you might see Xamarin merge into CoreCLR and rolled up into VS integration.
A lot of things are possible - but what's available right now is C++ on every platform and not much else.
We use Clang 3.5.
That said, there is always a cost to using a non-standard language to develop for a platform. Things like having to translate documentation as you read it, friction between system libraries and your languages standard library, etc.
I've not looked at Kotlin in detail, but I wonder how much that friction is reduced because it's java-based, or if you'll experience just as much friction using Swift on Android as you would using Kotlin on Android. Worth evaluating if you're starting a project 6 months to a year from now as the Swift tooling for Android starts to mature.
As it stands now, I would have a look at Kotlin, but almost definitely write any projects started today in Java. Swift is nowhere near ready, and the advantage of writing in the platform's "native" language usually outweighs any benefits there are to using a "better" language.
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.
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.
Can't a native library call just anything from the Android/Java world?
I mean, NDK library has JNIEnv* pointer and it can call FindClass/GetMethodID/Call*Method. And it can create objects/functions if it needs to be called back. Of course this isn't fun in the raw form, but don't see any reason it can't be well sugared.
Have you used the NDK? You cannot even access the filesystem outside the APK deployment tree without a few JNI calls.
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 doesn't work for you.
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 lot less time if we simply tried to find the best tool for the job, rather than joining with a group and sticking with them blindly.
Also, let's see how both languages gain traction in the next 3-5 years.
There is certainly a niche where it can be useful, but for most developers, it makes it a no go.
Kotlin on the other end is indeed a very good stand-in replacement for java on Android.
The target is probably iOS developers.
I have a distaste for Java but it's performance problems stem mostly from the way people write it and how hard it discourages writing in a performant style.
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 with ARC and in the vast majority of cases it does the best that can be done, which is why almost everyone uses ARC now. (You can still turn it off if you really want in ObjC)
>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.
Since we are discussing targeting Android: Java (and Kotlin) are also compiled ahead of time by the Android Runtime (ART). This has been the case since Android 4.4 (KitKat) when ART became an optional replacement to Dalvik.
[1] https://developer.apple.com/library/ios/documentation/Swift/...
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.
I think there are lot of iOS programmers in the wild for whom SWIFT is first language and hence the fascination.
Given the above, I don't see much point in using Swift, unless it's one of these projects that are about proving a point (nothing wrong with that and often very interesting).