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 runtim…
> Why would I ever care about Go for Android when I can write apps in Kotlin Power consumption.
I guarantee you could write a more power efficient app using the Android SDK versus Go in the NDK.
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 runtim…
Kotlin 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 lang…
It'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.
I wouldn't read too much into that. Android ships with Bionic libc, which is different from the glibc that is usually shipped in a Linux distro. There are definitely some differences between the two. Plus the average Android app is very far from the average Linux app. If they were aiming at supporting Android, I think they would have said that instead of Linux.
The key word here is "partly" Swift. I would not put it past Apple to use an intermediary framework that hosts a Swift runtime and calls into native Android APIs. That keeps the non-UI logic in one codebase.
That's more or less what they do with iTunes, isn't it? I recall there being an incomplete library packaged with iTunes once upon a time (with stuff like a stub implementation of Grand Central Dispatch that was neither grand nor dispatching).
I think part of the parent comment's point was that Swift does/will have a lot of users. Right now those 10,000 Go questions cover a lot of server related issues; the 37,000 Swift questions are almost completely iOS questions. If I started writing an HTTP server in Swift the day it comes out I won't find much help but I'll have a mountain of unrelated answers to filter. Essentially Swift's adoption for iOS apps doesn…
Objective-C never caught on outside of the Apple/NeXT ecosystem because its biggest advantages were in the application frameworks, not the language itself. By the time iOS made Objective-C popular there were entrenched alternatives in the C++, Java, and .NET ecosystems. Swift is facing the same challenges, but against a newer generation of competitors that are much less established. It's probably still an uphill batt…
Not to mention, Swift the language itself, which is basically Rust with arguably an easier memory management model (all ARC) and Scala-like pragmatism (an OOP model built-in). Coming from ObjC, developers are showing a high level of interest in Swift. I might look it up when it comes out for Linux!
Will Swift be an ISO or ANSI standard? Consider that while Objective-C is open source, Objective-C 2.0 was produced without any effort at all at standardization. I attended the 2008 WWDC. One of Apple's engineers was demonstrating Objective-C++ and actually said "You can freely mix objective-c and c++." I wanted to start screaming, maybe beat him senseless. I've done quite a lot of Objective-C, and quite a lot of C++…
> I've done quite a lot of Objective-C, and quite a lot of C++ but I'm still not sure I can figure out how to mix the two. By using Objective-C++. Just name your source file with the .mm extension and Xcode automatically starts compiling it as Obj-C++. If you take Objective-C, remove all the C from it, and take what's left and slap that on C++, that's Objective-C++. And it really does work, and prior to Swift's annou…
Supporting Linux is a surprise, but I think it's a great move on their part. Think: How many iOS apps are frontends to a server API? And how many of those APIs are running on Linux servers? Swift on Linux means ~all the code for a client-server iOS app can be written in the same language.
It's great news. Hopefully there will be a node-like ecosystem for writing small services on Linux soon. With F#, Swift and C# available, hopefully the proliferation of Javascript can be slowed on the server (without people running to Go).
I'll second that when Apple and MS will support Vulkan on their OSes and open codecs in their browsers. Or to put it another way, when they'll stop using sickening lock-in to make life harder for everyone.
As far as Vulkan goes, that seems to be on the graphics manufacturers.
AMD makes chips for Xbox and PlayStation. And they contributed Mantle to Vulkan. But I doubt it's only up to them to actually support it on the corresponding OSes.