Google May Adopt Apple's Swift Programming Language For Android, Says Report (thenextweb.com)

An anonymous reader writes: Google has plans to make Apple's Swift object-oriented language a "first-class" language for Android, reports The Next Web. The publication, citing sources, adds that Google doesn't mean to replace the current first-class language for Android -- Java -- at least, "initially." Google sees an "upside" in using Swift, which Apple made open source last year. But a ton of things need to fall into place for this to work. From the report, "All told, Google would have to effectively recreate its efforts with Java -- for Swift. If the company is motivated enough, it's very possible to do so without compromising on its open source values or ruffling any developer feathers along the way." The company is also discussing internally about making Kotlin as a first-class language for Android. "Unlike Swift, Kotlin works with Android Studio, Google's IDE for Android development. Unfortunately, sources tell The Next Web that Google's current mindset is that Kotlin is a bit too slow when compiling."

Comments

Opt for Swift, not Kotlin. Please!

[Anonymous Coward]

I would much prefer to see them go with Swift.

I've dabbled with both Swift and Kotlin, and the Swift community is a much nicer one to deal with. The Swift community is a lot like the Python and C# communities. They're friendly, not too opinionated, and when they are opinionated it's because they're right. If you have a problem, they'll help you out and everyone's happy. They aren't there to tell you what to do or how to do it. They just try to help you do what you want to do.

I've found the Kotlin community to be more like the Rust, Ruby and Nim communities. There is a lot of cockiness, and they're way too opinionated, especially when their opinions are factually wrong so often. If you don't do things their preferred way, even if their way is the worst way possible, well you can just fuck off and die as far as they're concerned.

Maybe the difference has to do with the age of the participants. Those working with Swift, Python and C# tend to be older, more mature and generally laid-back. Those working with upstart languages like Kotlin, Rust, Ruby and Nim tend to be young, angry, passive-aggressive, and perhaps impotent.

If I were developing for Android, I'd much rather deal with the Swift/C#/Python type of community than the Kotlin/Rust/Ruby/Nim type of community.

What happened to C?

[GuB-42]

On GNU/Linux, you can use whatever langage you want as long as it supports the C calling conventions, and most of them do. Same thing for oldschool Windows and pretty much every system running native code.
Why should a platform be tied to a particular language?

Re:What happened to C?

[squiggleslash]

For what it's worth, you can program Android in C. It's not recommended.

C is widely considered unsafe, a language that makes it far too easy to accidentally introduce security holes that end up with attackers being able to execute arbitrary code. Managed languages like Java aren't perfect, but they fix 90% of these errors, leaving developers able to focus on the types of error that are because something was badly designed, not because a buffer's size is too small for the data being read into it.

Mobile operating systems have enough security problems as it is without making it easier for programmers to introduce more.

Java, FWIW, has only two major problems: it's absurdly bureaucratic, and its master, Oracle, isn't really happy with anyone writing incompatible variants of it and is trying to prevent that from happening.

Meanwhile, nothing else has taken off. C# is almost as bureaucratic as Java, and, well, then there's Swift, but I'm having difficulty believing Apple will be less possessive of it than Oracle is of Java.

Re:What happened to C?

[GuB-42]

C is widely considered unsafe, a language that makes it far too easy to accidentally introduce security holes that end up with attackers being able to execute arbitrary code. Managed languages like Java aren't perfect, but they fix 90% of these errors, leaving developers able to focus on the types of error that are because something was badly designed, not because a buffer's size is too small for the data being read into it.

Right, but the core of Android (where security matters the most) is actually C or C++. In unprivileged mode, where apps run, security is important but not as much, because that arbitrary code will have no more permissions that the exploited app. Also, nothing prevents you from using a safe language that have C bindings.
But there are advantages to managed languages, which bring me to...

Meanwhile, nothing else has taken off. C# is almost as bureaucratic as Java, and, well, then there's Swift, but I'm having difficulty believing Apple will be less possessive of it than Oracle is of Java.

C# is just the tip of the iceberg, the CLI backend is the interesting part here. There are plenty of languages that target the CLI platform (see: https://en.wikipedia.org/wiki/... ), no lockdown here. For me, this is how managed should be done. And now that Microsoft opens up a bit, that's even better.

Re:Not JVM

[Phydeaux314]

I do some application development in Swift on iOS. It's... well, it has some issues, many of which stem from the issues you've pointed out.

First, not every interface or function you need is available in Swift, so you end up spending a lot of time converting back and forth between the two languages in your code. This massively increases complexity and is generally a Giant Pain In The Butt. I really wish they'd finished making their system calls on iOS available in Swift (rather than having to bounce back to objective-C all the damn time) before they pushed it out to the public.

Second, swift (and specifically how they use it on iOS) is an irritating blend of "we want things to be user friendly" (read: idiot proof) and "we don't want to hide too much out of the way." As a result, people coming from lower-level languages (like C or C++) will spend time fighting a some of the assumptions the system makes, and people coming from higher-level languages (like Java or Python) oftentimes will fall through the gaps.

Take memory management, for example - it has garbage collection, so you don't need to worry about malloc and free, but it doesn't have extensive garbage collection, so as soon as you start using multiple references - sorry, pointers - in multiple places you start needing to worry about keeping track of how you're referring to things (strong vs. weak) so you don't end up using more memory than you need to.

So, no, I don't really like Swift. It's not bad, and I'd work with it if I had to, but it's sort of sitting awkwardly between something lower level and something higher level and fully abstracted, and figuring exactly what they did and did not include is a pain in the butt to work with and around sometimes.