Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Android Google Java Open Source Oracle Programming Apple

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

Posted by msmash from the ditching-java dept.
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."
This discussion has been archived. No new comments can be posted.

Google May Adopt Apple's Swift Programming Language For Android, Says Report More

Google May Adopt Apple's Swift Programming Language For Android, Says Report

Comments Filter:

  • God damn it, just PICK A FUCKING LANGUAGE ALREADY! (Score:3, Funny)

    by Greyfox ( 87712 ) on Thursday April 07, 2016 @06:12PM (#51864167) Homepage Journal
    Damn it Google, just pick a fucking language already and make it an option as an alternate to Javascript on the browser. Anything strongly typed and notably lacking in magic goddamn bullshit (Looking at YOU, Ruby) would be better than what we have now.

    • Re:God damn it, just PICK A FUCKING LANGUAGE ALREA (Score:5, Insightful)

      by Jeremi ( 14640 ) on Thursday April 07, 2016 @06:18PM (#51864223) Homepage

      Damn it Google, just pick a fucking language already and make it an option as an alternate to Javascript on the browser.

      I thought the trick for web browsers was to pick your own favorite fucking language, and compile it to JavaScript for deployment? Then every programmer can use whatever language he/she prefers, rather than everybody having to use the same language.

      Of course, this article isn't about web browsers, it's about application development.

    • Re: (Score:1)

      by Anonymous Coward

      Next year's announcement: as we've realized that Swift wasn't invented by Google, we're deciding to replace it with a new own in-house language that will sit beside Go, Dart, Angular, and the rest of our toys that suckers think will be godsends, until we've got 'em hooked and change how everything works again.

      Next-next year's announcement: we're dropping support for the Internet, as we've realized that it wasn't invented by Google. We're making our own version, as in-house studies have shown that we can sav

    • WebAssembly is on the way. Soon you'll be able to program in any language for the browser.

    • Damn it Google, just pick a fucking language already ...

      Really? In my experience, this is one activity that doesn't in itself require much in the way of language skills; others may have a different perspective, of course.

  • Opt for Swift, not Kotlin. Please! (Score:3, Interesting)

    by Anonymous Coward on Thursday April 07, 2016 @06:18PM (#51864227)

    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.

    • Re: (Score:3)

      by jrumney ( 197329 )

      when they are opinionated it's because they're right.

      Isn't that true for any community (for their own definition of right).

    • I am curious where node.js/V8 stands... Coming from a C++, C# background,I am trying to learn 'the next' thing, and javascript with it's write once run anywhere seems like a very good idea.

      • Don't forget about React Native. Write native IOS and Android apps using JavaScript.

      • Re: (Score:2)

        by KGIII ( 973947 )

        I've been getting back into both programming and coding lately. This is after a nearly 10 year hiatus or a 15 year coasting period. I really haven't done much since about 2001. Some small stuff online, that's it. I did some stuff with SMF for a while, was on their team actually, and I stopped that in 2007 or 2008.

        The thing I've noticed is how much has changed. Oh wow... But, to be more specific and lend what I can, I've noticed that there's a JavaScript library for everything. There's also a Java library fo

      • The Javascript tech stack is in huge flux right now, with new frameworks coming out, and no convergence yet (this list isn't anywhere near complete [noeticforce.com], for example. If you really want to, and only have time to learn one, I'd go with Angular or Backbone. React.js is interesting but is still immature).

        The biggest coming wave is WebAssembly, which will let you write front-end code in C++. It's going to turn everything on its head, and my guess is we'll see completely new frameworks.

  • and be done with it. RemObjecs Elements [slashdot.org] compiles Swift/C#/Oxygene(Delphi-lile language) to ios/windows/java/mac.

  • Not JVM (Score:5, Informative)

    by Anonymous Coward on Thursday April 07, 2016 @06:27PM (#51864273)

    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 (Score:5, Interesting)

      by Phydeaux314 ( 866996 ) on Thursday April 07, 2016 @07:34PM (#51864679)

      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.

      • Take memory management, for example - it has garbage collection, [...]

        No, it has not.

        Swift uses Automatic Reference Counting (ARC) [apple.com].

        Stop developing now until you read and understood that document.

      • Re: (Score:3)

        by Elledan ( 582730 )
        My approach to mobile development (Android & iOS) is to write all of the logic and everything else I can in C++ ('Objective-C++'), then use some glue logic in Java/Objective-C/Swift where needed and native APIs aren't available.

        Writing an entire app in Java, Objective-C or Swift seems illogical, even if the app isn't intended to be cross-platform. Just being able to debug the core logic with mature C/C++ tools on a Linux/BSD PC is a godsend, and reusing the same code across two (or three, or four) mob

        • Yeah. I like Swift, but the debugging isn't mature yet. XCode regularly crashes when you start putting breakpoints or single stepping though Swift.

    • Re: (Score:2, Insightful)

      by Alomex ( 148003 )

      The JVM exists because Sun assumed Java would be running in very different devices without a proper OS and without ready access to a native compiler. None of these things hold true today. So the JVM is essentially just a layer of cruft slowing down your app. Android nowadays compiles the app into native code and modern JVMs compile at run time. So let's get rid of the JVM.

      • Re: (Score:2)

        by Kartu ( 1490911 )

        JVM has no problem being performant (thanks to advanced JIT, which, at least in theory, can even be faster than static compiler, as it has runtime information such as which branch is more likely to be taken).
        The only inherent disadvantage of it is memory footprint.
        But that's the price you pay for not having to malloc/free.

        • Not necessarily, reference-counted memory management, plus weak pointers if you insist on creating circular references, free you from freeing, and don't have a memory penalty.

        • Re: (Score:2)

          by Alomex ( 148003 )

          You are ignoring two other disadvantages: the power consumption of the first compilation pass is non-negligible, and the garbage collection mechanism creates quite a bit of overhead. So while in theory the JIT could be faster in practice it has never been. So if we are now JIT compiling (which precludes static analysis and optimizations) what is the use of the JVM?

    • Re: (Score:3, Informative)

      by lokedhs ( 672255 )
      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

      • Yes, there are trade-offs in both directions. Apple made the choice for ref-counting so that you have a consistent UI experience and generally lower memory overhead. For phone based apps I think this is the right choice. By the way, I don't think you can say that a GC is faster, just that it can be faster, in the real-world it can also be slower depending on how it's being used.

        Personally I find GC to be a pain the rear due to the fact that it's generally a lot harder to resolve GC performance issues that

        • Apple made the ref-counting choice decades ago and now has to keep supporting it to maintain compatibility with their APIs.

      • There's also the fact that garbage collectors tend to require much more memory in order to maintain performance than reference-counting schemes. This is a huge part of the reason why Android requires so much more RAM than iOS.

        This also means that performance just tanks on devices that rely on GC as memory gets close to full, which can lead to really nasty experiences.

        I really think that making use of a garbage-collected language as the primary language in embedded devices is a bad, bad idea all-around. I

        • Given Oracle suing Google for IPR issues on their Dalvik rip-off of Java, it seems quite likely. Swift is open source and so doesn't carry that problem.

          They could use another language other than Swift and Java. But Swift is fit for purpose, having been designed specifically with smartphones in mind. And although young, already has a lot of mobile developers who know it.

    • Re: (Score:2)

      by Hizonner ( 38491 )

      As a user, having seen the kind of code that's actually offered for me to use, I don't want it to be any easier than it absolutely has to be to leak memory. It can be really easy to drop a cyclic reference, or conversely really hard to keep track of when you have them. The programmers writing phone apps have shown that they're not up to that kind of challenge.

      In this day and age, programmers shouldn't have to think about the internals of the runtime. Stuff should just work. And I'm willing to take a perform

    • Garbage collection doesn't detect cycles. Garbage collection ignores a second reference to an object (as would be created by a reachable cycle, but also happens just normally), and garbage collection ignores unreachable objects (which may include complete cycles that are unreachable, but also any other object or a tree structure that isn't reachable).

  • Google has put a ton of effort into Go, why not add that as a first class language as well?

    I suppose Go/Java syntax are "close enough" at a high level. But kotlin? There are only so many ways to shuffle C & Pascal syntax before everyone is dazed and loses interest.

    • Re: (Score:1)

      by Anonymous Coward

      Go has no classes, swift has, It would be painful migrating a large api surface that currently heavily relies on classes to a language that has minimal support for OOP.

  • What happened to C? (Score:5, Interesting)

    by GuB-42 ( 2483988 ) on Thursday April 07, 2016 @06:49PM (#51864405)

    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: (Score:3)

      by Lisias ( 447563 )

      Because corps wants to have locked in mindset developers tied to their solution.

    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Thursday April 07, 2016 @08:07PM (#51864847)
      Comment removed based on user account deletion

      • Re:What happened to C? (Score:4, Interesting)

        by GuB-42 ( 2483988 ) on Thursday April 07, 2016 @08:47PM (#51865083)

        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/... [wikipedia.org] ), no lockdown here. For me, this is how managed should be done. And now that Microsoft opens up a bit, that's even better.

        • 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.

          I do not agree with this statement. The Towelroot kernel vulnerability impacts some KitKat and all versions below - any app that is able to download a small binary and run it from a shell can obtain root privilege.

          KitKat and below are over 50% of the Android ecosystem at the moment, and app privileges are dangerously weak there.

      • Unsigned int would be awfully nice ...

        https://en.wikipedia.org/wiki/... [wikipedia.org]

      • Re: (Score:3)

        by fuzzyf ( 1129635 )
        I think C# is getting really interesting. Watching the language specs being discussed and implemented on github is very nice.

      • Re: (Score:3)

        by jeremyp ( 130771 )

        I'm having difficulty believing Apple will be less possessive of it than Oracle is of Java.

        Swift is already open source and while the core developer team (Apple employees) retains a firm grip on the language's direction, they have a process whereby anybody can propose new features for the language.

        https://github.com/apple/swift... [github.com]

        • I prefer a firm grip over a language over adding features without much afterthought, and then having to support those for all of eternity.

      • Re: (Score:2)

        by Nemyst ( 1383049 )
        Actually, I'd say that C# is a pretty good middle ground. It still has a "master" in Microsoft, so you don't have the design by committee issues (no clear direction, slow development cycles, etc.), but they've also been listening to feedback and implementing it pretty consistently, on top of adding their own stuff. As a result, C# has evolved really quickly and overtook Java many releases ago. They keep pumping out more features, from the convenient to the groundbreaking, with every release. With the openso
    • Yeah, that's a good idea. Make the base libraries in C, then any language can use it.

    • Android does let you write your apps (or at least, the bulk of them) in C or any other language your want. But it's not the recommended approach. A lot of its libraries are written in Java, so you have to jump through a few extra hoops to use them if your code is running outside the VM. And you have to worry about providing binaries for different architectures, whereas with Java it takes care of that for you.

      So you presumably could already use Swift when coding for Android. But that's not what this is a

  • 1. Google adopts Swift programming language!
    2. iOS developers port their iPhone apps to Android!
    3. ...
    4. Profits!

    • Re: (Score:2)

      by Kartu ( 1490911 )

      I frankly think this is most likely just an attempt to bring attention to Swift.
      It's hard to imagine Google switching to it, to say the least.

      • Yeah, that'd be like Google basing their Browser on Apple's open sourced WebKit... and then forking it... Oh...

  • Why not just use c#? (Score:3)

    by Barlo_Mung_42 ( 411228 ) on Friday April 08, 2016 @12:34AM (#51865833) Homepage

    It's already open source and it already runs well on Android. What do they think they'll gain by doing a bunch of work to use Swift?

  • Have they learned nothing? (Score:3)

    by sad_ ( 7868 ) on Friday April 08, 2016 @05:46AM (#51866617) Homepage

    Google has, how many languages that they developed themself available they can use?
    But still they would pick a language, not developed themselves, but by a competitor.
    And they would do this why? Because they didn't learn from the whole Java debacle?

  • This has all the smell of a response to Microsoft's purchase of Xamarin. By extending their reach, Google is attempting to diminish the effect C# may have on their ecosystem.

  • I know that Go is being pitched as a systems language - but surely it would be easier for Google to do the work necessary to switch to Go and improve it than use Swift.

    Based on my (brief) look at Swift it seems to me that they have tried to be too clever by half - throwing everything in to it. Love or hate Java, C, Go - they have the benefits of being clean and simple languages.

Slashdot Top Deals

Life is a whim of several billion cells to be you for a while.

Close