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

Not JVM

[Anonymous Coward]

I hope they don't intend to run Swift on their JVM.

What makes Swift so performant is that it lacks a tracing garbage collection. It only uses reference counting. Reference counting is a kind of garbage collection, but it doesn't by itself detect cycles. It's the cycle detection that is costly in languages like Java or Python (which uses reference counting along with a tracing collector for cycles.) People argue that cycle detection is cheap, especially in generational GCs. But the generational assumption presumes too much. Likewise when passing references between threads. Cross-generational (yet temporary) and cross-thread value passing can happen often. (See, e.g., MoarVMs problems.)

Plus, tracing collectors often need 2x RAM to be performant. Again, people wave away that requirement by arguing RAM is cheap and plentiful. But that assumption is broken all too often, as well, _especially_ on embedded devices.

So Swift offers both lower latency, more consistent latency, and requires fewer CPU and RAM resources. The cost is that you have manually break cycles, otherwise you'll leak memory. But tracing collectors don't fix all leaks, either. It's common to "leak" memory through caches. Some languages provide ephemerons (e.g. ephemeron tables in Lua), a special reference type that is more semantically powerful than, e.g., weak references, and provides the necessary hints to the tracing collector. But it's still something you must explicitly declare. And the Big-O complexity of ephemerons is pretty bad, so it can degrade performance significantly if there are lots of cycles passing through the ephemeron.

Re:Not JVM

[lokedhs]

I wouldn't be so quick to assume that reference counting requires less CPU cycles unless you have actual data to back up that claim.

With reference counting every single allocation, as well as every single object ownership transfer requires extra CPU cycles and memory accesses to manage the memory as well as manage the counter (yes, I know Swift does some clever tricks to avoid the counting which frankly is the only reason it's as performant as it is). Also remember multithreading issues when updating the refcounter.

With garbage collection, you obviously don't need to do any reference counter management, saving a lot of CPU and memory access cycles right there. But what is less obvious is that memory allocation itself is much faster with (compacting) garbage collector. After collection, all free memory will be in a single contiguous block, reducing the memory allocation operation to a single ADD instruction.

So, in summary:

With refcounting you have:

• Slow memory allocations (need to manage a fragmented heap)
• Slow accesses and pointer handovers (updates to the refcounter)
• Slow free (need to manage the free list)
• No asynchronous pauses (since there is no garbage collector)

With a GC, you get:

• Fast allocations (usually just an "add" instruction since the heap is not fragmented)
• Zero cost accesses and pointer handovers
• Zero cost free (just stop using the pointer)
• Some asynchronous pauses and CPU usage while running the GC

There have been plenty of research on memory management, and we're well past the time when you could say "GC is slower than the alternative".

Re: Opt for Swift, not Kotlin. Please!

[tepples]

What do you need a community for? Read the language spec, read the api spec, done.

For helping to clarify things that you failed to understand in said specs, and to help explain practical ramifications of said specs.

Re:God damn it, just PICK A FUCKING LANGUAGE ALREA

[Anonymous Coward]

The browser developer tools actually support source "map" files that allow you to step through the source - it's already used in the case where you concatenate and minify multiple javascript files into one

Re:God damn it, just PICK A FUCKING LANGUAGE ALREA

[TheReaperD]

compile it to JavaScript

That word. I don't think it means what you think it means.

Re:God damn it, just PICK A FUCKING LANGUAGE ALREA

[HiThere]

I think it actually does. At one point CDC was contemplating a machine that was going to use APL as the assembler language, to which other languages would need to compile if they were to run as native. So JavaScript can define a virtual machine that can be compiled to.

Now whether that's a good idea is a different question.

Re:Apple fucked up

[D.McG.]

Apple open sourced the language. They did NOT open source UIKit, CoreAnimation, etc. Many iOS devs are Android devs as well. While this will allow for a common language between the UI and the shared C++ code, the UI code will still be platform specific.