back to article Apple to tailor Swift into fully open-source language – for Linux, too

Apple will release version 2.0 of its Swift programming language as open source, with the aim of getting it everywhere. "We think Swift is the next big programming language," Apple software engineering veep Craig Federighi said during Monday's keynote address at the annual Worldwide Developer Conference (WWDC) in San Francisco …

  1. Anonymous Coward
    Anonymous Coward

    Once it goes Open Source

    Will a Windows version be far behind?

    1. mafoo
      Mushroom

      Re: Once it goes Open Source

      No, because Microsoft is already throwing considerable resources at porting Objective C to visual studio - and this will make bringing swift over a lot... swifter.

      I'd also expect them to have some form of Appkit mimicking framework in the works as well.

    2. Deltics

      Re: Once it goes Open Source

      Far behind? It's already available...

      http://elementscompiler.com/elements/silver/

      Just not from Apple. And not just for Windows (.net), but for Java (and thus Android) too!

    3. werdsmith Silver badge

      Re: Once it goes Open Source

      If Objective / Swift is stepping outside the Apple world then I will make an effort to start using it.

      Every time I've tried to get into a new coding world I always end up slipping back to C/C++ like a comfortable old jacket.

  2. Alan W. Rateliff, II
    Paris Hilton

    Tailor Swift...

    *snort* I see what you did there.

    1. DNTP

      Re: Tailor Swift...

      They've done this at least several times before on Swift headlines. But the good thing is it will never stop being funny.

  3. Mad Hacker

    Just like FaceTime...

    Remember when Steve Jobs said FaceTime was going to be released as open source? Yes I'm still bitter.

    1. Richard Taylor 2 Silver badge

      Re: Just like FaceTime...

      Got to confess I don't remember that. But Swift has a number of very nice features - SML for the masses.

    2. chr0m4t1c

      Re: Just like FaceTime...

      Unfortunately, VirnetX lobbed a sueball and won the case. Apple had to re-write the way FT operates in such a way that avoids those patents and in the process made it worthless as an OS project.

      IIRC the patents were around P2P connections used in the old version, the re-write means the connections are now made through a central server.

      So you'd either have to OS the server software as well - and rely on people setting up their own servers - or you'd have to route all of your FT communications through Apple's servers.

      Neither of those options strike me as something you'd really want.

  4. This post has been deleted by its author

  5. JLV Silver badge
    Happy

    thoughts on Swift as a general language?

    (good news, always nice to see more language options available, though most peter out quickly enough.)

    I keep on meaning to check out Swift myself but haven't gotten around to it.

    For those who have wrestled with it already, how is Swift's support for namespaces/module/package names? Had a talk with someone claiming it wasn't very good compared to C#'s. Saw some verbiage claiming both ways on SO, none the wiser for it. Can you differentiate moduleA.someclassname from moduleB.someclassname and use both those classes, easily?

    And on a more general note, what are the design features that you disagree with? (besides Apple's parentage if that's not your thing)

    Basically, I expect that, like for any software, any documentation will concentrate on Swift's virtues. Any be somewhat silent about its shortcomings.

    Sometimes it is good to follow along while knowing which weak points to pay attention to rather than finding out dead ends later.

    p.s. Could we have a less disturbing nicer pic of Taylor? They do exist. Still no need for an audio option on this article however ;-)

    1. Fred Flintstone Gold badge

      Re: thoughts on Swift as a general language?

      I think Swift's main attraction is that it's one platform to bind them all :).

      I suspect the cunning plan is that by bringing Swift into Open Source, Apple ends up with more people feeling capable of developing applications for iOS and OSX, but being able to code doesn't immediately imply an ability to make it user friendly.

      It'll be interesting to watch what happens. Apple tends to be less into public beta testing so I don't think it's a big risk for coders to invest time in Swift (it's not going to disappear overnight), but what interests me is how quickly they will adjust any issues or add missing features. Apple has never struck me at being terribly good at communicating (and by that I mean two-way, not marketing :) ), and Open Source only really works with bidirectional engagement.

      What would make it really interesting is if an Android SDK emerged from a 3rd party, which is possible if it's really Open Source. I don't think it would harm Apple much, but their reaction would be worth watching.

      1. Deltics

        Re: thoughts on Swift as a general language?

        When did people forget that language <> platform ?

        I blame Microsoft and Sun/Oracle. They successfully conflated the two with Java and C# but as others have demonstrated, this is still just a conflation, not an equation.

        If you want to do Android development using Swift you already can.... Use RemObjects Silver, an implementation of Swift from RemObjects with backend compilers for .net, iOS/OS X or Java (and therefore Android).

        Although hosted in Visual Studio, you can even launch directly into Android Studio for doing your Android layouts visually, if you wish. You also use Xcode Interface Builder for your iOS/OS X UI designs in projects for those platforms (although for technical reasons you can't launch directly into Xcode in the same way that you can with Android Studio).

        From the same company, for all of these platforms you can also use C# or Oxygene - their own very slick implementation of a very modern Object Pascal (with much to recommend it over its curly bracketed brethren).

    2. Torben Mogensen

      Re: thoughts on Swift as a general language?

      JLV wrote: "And on a more general note, what are the design features that you disagree with?"

      I admit that I may not be entirely up to date with the newest developments, but from what I remember from reading about it a while back:

      - The choice of reference counting GC. It is slow and it necessitates using weak pointer if you create cyclic structures such as doubly-linked lists. There are concurrent GC algorithms that would be much better.

      - That only objects are boxed. This makes it impossible to create a recursive enumerate without using objects.

      - A rather verbose syntax for enumerates, as well as a few other odd syntactic choices.

  6. dogged

    Unlike such languages as [...] C#, which execute in virtual machine runtimes

    Oh look, accuracy in journalism. Not.

    1. Kanhef

      The .NET CLR is a virtual machine.

      1. dogged

        .net code compiles to MSIL which in turn compiles to native using JIT.

        Short version is that it does, but no "vm" is required to run it, only the compiled assemblies it references.

        1. Deltics

          Whether compiled at compile time or JIT, .net code runs in the .net *VM*

          VM <> interpreter

          1. dogged

            No it doesn't.

          2. Deltics

            Whoever downvoted this statement of fact needs to check their basic comprehension of the subject on which they choose to wield their opinion. It will save them all sorts of embarrassment in the future.

        2. Deltics

          Q: Can you run .NET without the CLR ?

          A: No. The CLR is by DEFINITION part of the .NET execution environment. Without it nothing runs.

          Q: So the CLR runs the code. But what in Comp Sci terms is the CLR ?

          A: It is a VIRTUAL MACHINE.

          Q: Is it then true to say that all .NET code runs in a VIRTUAL MACHINE ?

          A: Yes. And anyone that says or thinks otherwise demonstrates in so doing that they are unqualified to comment further.

          Q: Ok smartass - what about MONO then ? That runs .NET code but it can't be in any .NET virtual machine because it is specifically not .NET but an alternative to it.

          A: Ok dumbass... read Mono's own definition of what it is... "The Mono runtime [is an open source implementation of the .NET] VIRTUAL MACHINE."

  7. Adam 1 Silver badge

    A directive by definition cannot be a runtime decision in a compiled language

    /pedant

  8. ST Silver badge
    Stop

    #available

    as opposed to

    #if defined(_FOO)

    #endif

    Magic!

    Let's see how many Fanbois dial it up to 11 explaining that It's Not The Same Thing!

    1. A Non e-mouse Silver badge
      Facepalm

      Re: #available

      Er, they're not the same 'cause the Swift #available is a run-time declaration, whereas the C #if is a compile time directive.

      Or is my sarcasm detector failing?

    2. gnasher729 Silver badge

      Re: #available

      If you tried to be sarcastic, you should have said so. Instead it seems you are just clueless. Then you used the trick to claim that everyone correcting your nonsense must be a "fanboi dialing it up to 11". That makes you clueless and a troll.

      For those who are interested: Let's say I want my application to run on iOS 7 and newer devices, but I want to use iOS 8 features if they are available. Obviously I can't use them when the phone runs only iOS 7, so a check must be done.

      if #available (iOS 8, *) {

      // Code that runs only on iOS 8

      } else {

      // Code that runs on iOS 7

      }

      And this works at runtime. The same code ships to all devices, and does the right thing on every device. So if you upgrade the OS on your device, you get new features in your apps without downloading a new version. Which would be impossible with the #if in the C or C++ preprocessor.

      1. Kristian Walsh Silver badge

        Re: #available

        I wouldn't be keen on adding syntactic sugar for something that smells of bad practice in the first place. Such runtime checks really should be used only to choose the appropriate interface implementation for your platform - littering your code with these directives will not help maintainability.

        Also, if that's the real syntax you've just posted, it's horrible, and at odds with how directives are used already in Swift. I had expected something like this:

        #if available( iOS_8 )

        blahblah();

        #else

        blah();

        sleep(1); // "it's time to upgrade your iThing, puny human"

        blah();

        #endif

      2. ST Silver badge
        FAIL

        Re: #available

        I don't think you understand how SWIFT is implemented, and the example you post above clearly demonstrates it. I don't think you understand how compilers work, either.

        Your example above is a gem of useless and clueless code bloat. What you are proposing is that, at run-time, the application should check if specific features are available. That's just dumb. For one, you'd have code which never executes. For two, you'd be needlessly checking if the code which never executes should be executed. Imagine having that run-time check in your example inside a switch() or a loop.

        This is precisely why conditional compilation was invented in the first place. So that unnecessary feature-tested code doesn't end up where it doesn't belong.

        Now it could very well be that SWIFT uses a two-stage compilation: Stage 1 from source code to LLVM bytecode, and Stage 2 from LLVM bytecode to binary opcode. In either case, the feature-tested code that wouldn't be available on a particular version of the OS would be eliminated during Stage 2 compilation. Just like conditional compilation eliminates unnecessary code by means of preprocessor conditionals in languages like C, C++ and others.

        Like I said: clueless Fanboi Fail, dialing it up to 11.

        And I almost forgot: in SWIFT, you can declare variable names in Unicode. Meaning, you can use Emoji as variable names. That's one feature I was dying for. Not.

        1. Fibbles

          Re: #available

          Your example above is a gem of useless and clueless code bloat. What you are proposing is that, at run-time, the application should check if specific features are available. That's just dumb. For one, you'd have code which never executes. For two, you'd be needlessly checking if the code which never executes should be executed. Imagine having that run-time check in your example inside a switch() or a loop.

          If you'd ever written an OpenGL* application you'd know these sorts of run-time checks are extremely common. Not all hardware is created equal. Unless you want to only ever code for the lowest common denominator you must check which features are available at run-time. It is not feasible to ship multiple binaries when the hardware you're programming against is as diverse as GPUs are. I suspect programming for the SoCs found in mobile devices is a similar situation.

          *Possibly DirectX as well, although I have no experience with it.

          1. ST Silver badge
            FAIL

            Re: #available

            > If you'd ever written an OpenGL* application you'd know these sorts of run-time checks are extremely common.

            1. This isn't OpenGL.

            2. OpenGL doesn't have its own compiler, nor is it a programming language. It's a collection of precompiled libraries.

            3. Yes, I've written OpenGL in the past.

            4. SWIFT is a compiled general-purpose programming language, not a special-purpose application-layer graphics library.

            1. Fibbles

              Re: #available

              WHOOSH. That is the sound of my point flying completely over your head.

              At no point did I suggest OpenGL was a programming language. You check at runtime for available features in the system's OpenGL implementation using whatever language you're writing in, be that C++, Java, Python or whatever.

              Similarly with SWIFT, you check at runtime if the library you're attempting to use supports the feature you want. The only difference is that SWIFT has a directive dedicated to the job whereas usually you'd have to use if/else statements paired with query functions provided by the library.

              1. ST Silver badge
                FAIL

                Re: #available

                > At no point did I suggest OpenGL was a programming language.

                Then why are you - STILL - comparing OpenGL to a general-purpose, compiled, programming language like SWIFT? Because Apples - pun intended - and Oranges?

                Do you even understand the difference between what a pre-compiled library can and/or cannot do at run-time, and what a compiler can do with source code at compile-time?

                It appears that you do not.

                Fanboi.

                1. Fibbles

                  Re: #available

                  Are you really this dense or am I being trolled?

                  Then why are you - STILL - comparing OpenGL to a general-purpose, compiled, programming language like SWIFT?

                  I didn't compare the two. I'm using an OpenGL application as an example of when you need to check at run-time which code path to use because it is not possible at compile time. If it helps focus your mind assume the application is written in C++. I used this example because you implied run-time checking was something that should never be done when clearly it has valid uses.

                  Fanboi.

                  I don't own any Apple products.

                  1. ST Silver badge
                    FAIL

                    Re: #available

                    > I'm using an OpenGL application as an example of when you need to check at run-time which code path to use because it is not possible at compile time.

                    That would be an implicit comparison, yes?. We're discussing SWIFT here, correct? Where does OpenGL or any other library's run-time feature tests fit into compile-time conditional compilation?

                    > you need to check at run-time which code path to use because it is not possible at compile time

                    Why is conditional compilation not possible at SWIFT compile-time? Who said that it isn't?

                    I've just explained to you that compilers try their absolute best not to emit this type of run-time checking crap. A compiler's first and foremost duty is to eliminate as much code as possible. Eliminate as in: No longer there. Gone. Deleted.

                    > assume the application is written in C++.

                    What does C++ have to do with OpenGL? OpenGL is written in C, not C++. Run readelf -s /usr/lib/libGL.so or /usr/lib64/libGL.so; you won't find any mangled symbols. It's all C. Even the proprietary blobs from NVidia or AMD/ATI.

                    Again. Why are you comparing what compilers do with what shared libraries do?

                    1. Fibbles

                      Re: #available

                      Eugh. Is English not your first language or something?

                      #available is for run-time feature checks. It is not a preprocessor directive. It does not strip redundant codepaths at compile-time.

                      1. ST Silver badge

                        Re: #available

                        > #available is for run-time feature checks.

                        Awesome then. It's not just your typical Apple Pile Of Crap, it's a total and complete Pile of Crap. An optimizing compiler which includes feature test code for every single version of iOS under the Sun.

                        At least Android can optimize for the device the software is installed on.

        2. razorfishsl

          Re: #available

          Microsoft is gonna love THAT feature.....

          The ability to include the code base of every product since the 8080

  9. justok

    Will this Swift still have commitment issues?

  10. efestnetz

    VICTORY !

    so we finally have the memory safe systems programming languages. the cyber crime/war domain can now be shrunken to reasonable size again.

    after decades of malpractice with the bug-enabler C, we return to the sanity of strongly typed languages. thanks to niklaus wirth and other allaman engineers.

    lets hope we can turn the it ship around before people start to use paper files again.

    1. efestnetz

      Re: VICTORY !

      I see the paper and microfiche industries are modding me down :-(

    2. Ian Joyner

      Re: VICTORY !

      Exactly - C has been the biggest problem in the industry costing billions per year just because you can point a pointer anywhere and overrun the end of arrays, etc. I think younger programmers are being better taught these days to appreciate type-safe language.

      While a lot seems based on Eiffel (which Apple certainly knew about), there do seem to be C-style explicit kludges making it in like try-catch, etc. Eiffel's exception handling is so much more elegant, being a part of the language from the base up, you don't need explicit try-catch.

      And why do they have to stick to the old-looking C syntax? Oh I'll answer that myself - because most of the industry is not ready to move past it. Something that used some beautiful typography to really expose the structure of programs in an intelligent editor would have been nice, but programmers usually are the last to accept such things.

      1. Ian Joyner

        Re: VICTORY !

        Further to my previous post saying that Eiffel's exceptions were subtle because they were baked into the language and runtime, rather than explicit like try-catch, I just saw this rather nice quote:

        "GOOD DESIGN IS OBVIOUS. GREAT DESIGN IS TRANSPARENT"

        at http://www.alivemobile.com/approach/#ourapproach

  11. Anonymous Coward
    Anonymous Coward

    microsoft

    ...could have had this, if they had done mre than copying java. essentialy they had almost every thing in their labs wity the c# based os kernel. if they only had some original analysis on languages. anyway, the internetvgot it figured out. now ms cwill playvcatchup. el reg s not nice to use from a phone...

    1. Anonymous Coward
      Happy

      Re: microsoft

      Have an up vote for this bit...

      "el reg s not nice to use from a phone..."

    2. dogged

      Re: microsoft

      > ...could have had this, if they had done mre than copying java

      C# is objectively (no pun intended) well ahead of Java in terms of feature completeness and has been for years. Dynamics, generics, Java only just got lambda expressions for Christ's sake.

      I'll agree that the concept is similar but Hjelsberg's execution is far, far better than Gosling's.

  12. Tim Almond

    Cross-Platform

    For simple, text and graphics apps, people are already tooled and schooled in Phonegap. Which will already deploy to a bunch of targets. If you're doing games, you're probably already using Unity. Does Swift work with PC, Xbox One, Wii U, PS4? So, who's going to go through wanting multiple codebases for all of those platforms?

  13. Andy E
    Thumb Up

    Significant lean towards iOS

    I have played with Swift writing a couple of demo applications on OS X. The problem I had was that at least 95% of the information out there is about writing code for iOS. While there is much in common there are substantial differences between the two operating systems particularly the UI.

    Having said that I do like Swift as its easy to write half decent code.

    1. Kristian Walsh Silver badge

      Re: Significant lean towards iOS

      I had the same problems learning C# - almost all of the documentation and tutorials are also telling you how to use .NET for Windows, and particularly Windows Forms, whereas most of my interest was in writing cross-platform control code.

      However, C# as a language can be used to write code for any platform, and so can .NET, if you stick to its Portable Class Library core. If you are looking for a guide, I recommend "C# in Depth" by Jon Skeet (pub. Manning), but you do need to be proficient in another language with C-family syntax (C, Java, C++) before beginning it.

      Incidentally, as noted elsewhere, C# is not necessarily a JIT-translated language. Although it is most often run via JIT compilation, you can pre-compile complete assemblies into native machine code at install-time. But mere native code does not a systems language make: C# lacks low-level memory access operators for one thing. Does Swift? It's not clear from the introductory docs...

  14. Sean OConnor

    Could we please lock Microsoft, Apple and Google in a room and only let them come out when they've all agreed on ONE language they're all going to use?

    1. Thecowking

      Good lord no.

      Homogeneity is a curse when it comes to programming languages. Let them muliply and let the good ones flourish and the bad ones die.

      1. dogged

        Also, you'd have lock Oracle in there too, and Larry Ellison bites.

      2. Sean OConnor

        I've got no problems with a bewildering array of different languages. It'd just be nice if we could choose one that's pretty good (I don't care which one) and each platform implements it.

        I can see a need for other languages on very different platforms like the web, but iPhones, Windows phones, Android phones and desktops all do basically the same job. It'd be nice if I didn't have to port my code over from Objective C to Java to C#.

        1. Anonymous Coward
          Anonymous Coward

          One language won't help much, given the mind-boggling array of different APIs.

  15. Anonymous Coward
    Anonymous Coward

    Exceptions??

    No thanks. This sounds like a kitchen sink language, not a systems language. I'll look at it if it's on Linux but only to see what the hype is all about.

  16. Paul 75

    Android please!

    I'd love to see this running on Android, so much less porting work would need to be done.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019