Introducing Swift - <AUTHOR> https://developer.apple.com/swift/ <comment><USER4> As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :)

Software-wise, I feel these current WWDC announcements are the most exciting in years.

Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediately after the parentheses), closure expressions, strong Unicode character support, a very very neat alternative to nullable types with " _Optionals_ ". Operators are functions, too.

It has the concept of explicitly _capturing_ variables from the surrounding context inside closures, like PHP does, instead of keeping the entire context alive forever like Ruby or JS.

Hell there is even some shell scripting thinking in there with shorthand arguments that can be used as anonymous parameters in closures, like "sort(names, { $0 > $1 } )".

Inside objects, properties can be initialized lazily the first time they're accessed, or even updated entirely dynamically. Objects can swap themselves out for new versions of themselves under the caller's nose by using the _mutating_ keyword.

There is the expected heavy-weight class/inheritance scheme which accommodates a lot of delegation, init options, bindings, and indirection (as is expected for a language that must among other things support Apple's convoluted UI API). But at least it's syntactically easier on the eyes now.

Automated Reference Counting is still alive, too - however, it's mostly under the hood now. Accordingly, there is a lot of stuff that deals with the finer points of weak and strong binding/counting.

Swift has a notion of _protocols_ which as far as I can tell are interfaces or contracts that classes can promise to implement.

I think generally there are a few great patterns for method and object chaining, function and object composition in here.

The language has C#-style _generics_ , and supports interesting type constraint expressions.

<comment><USER5> I really don't see the Golang influence at all. The multiple- return- value semantic is closer to Ruby's than to Golang's; you're returning a tuple, which happens to have natural syntax in the language.

Defining Golang features that don't exist in Swift:

\- Interface types with implicit adoption (Swift takes explicit protocols from ObjC)

\- Error types

\- Relatedly, the "damnable use requirement" and its interaction with error types and multiple value returns (ie, the reason Golang programs in practice check errors more carefully than C programs).

\- Slice types

\- Type switching (though, like Golang, it does have type assertions)

\- "defer"

\- Of course, CSP and the "select" statement.

Swift features that don't exist in Golang:

\- Generics

\- Optionals

\- A conventional, full-featured class-model

Of the languages you could compare Swift to, Golang seems like one of the biggest reaches. Even the syntax is different.

(I like what I've read about Swift and expect to be building things in both Golang and Swift, and often at the same time).

<comment><USER6> > \- Interface types with implicit adoption (Swift takes explicit protocols > from ObjC)

Objective-C has informal protocols, and so does Swift.

<comment><USER7> Informal protocols and implicit interfaces are not the same thing. In particular, implicit interfaces are type checked statically at compile time, while informal protocols are checked dynamically at runtime.

</comment></comment></comment></comment><comment><USER8> I'm not even an iOS developer but this is by far the most exciting thing I heard in the keynote.

As an amatuer/hobbyist programmer who's self-taught with Ruby, JavaScript, etc., the one thing that was keeping me from experimenting with iOS apps was Objective-C. I know I could tackle it, but it's been hard to take the plunge.

I don't know much about Swift yet, but from what I've seen it looks very exciting. So if Apple's goal was to get new devs into the iOS world, at least from 10k feet, it's working.

I'm excited!

<comment><USER9> I don't get the hate. Yeah, syntax is unfamiliar, bu once I got used to it I began to really enjoy objective-c. Ymmv etc., but it's now one of my fav languages - though I guess this is mostly due to cocoa

<comment><USER10> You may not hate Objective-C, but I doubt you love it either. Have you / would you ever use Objective-C to write a web back-end? To write a command-line tool?

<comment><USER11> I got started with WebObjects, a Next product a couple years before Apple bought them. Yes I've written wonderfully powerful web applications in Objective-C back when the rest of the web was being built using CGI and Perl scripts.

I loved Smalltalk and I love Objective-C at a deep level. The Objective-C runtime is incredibly powerful and its method dispatch is astonishingly efficient considering what it does. It is not as fast as vtables, but it isn't as fragile either.

It might well interest you to know that WebObjects (I'm talking 1997 here) ran on HP-UX, SunOS, AIX, and one other popular Unix of the day that slips my mind and it too shipped with a lively scripting language called WebScript which was not so different from a minimal Swift today.

The thing is, once you dig into the Objective-C runtime and spend a bit of time trying to write an interpreter, you start to realize that the interpreter almost writes itself. Swift is far from the first language built atop the Objective-C runtime.

Consider FScript ([http://www.fscript.org](http://www.fscript.org)) has been around for well over a decade and does more or less the same thing except it gives you something closer to Smalltalk than Javascript and it includes some advanced matrix manipulation goodies as well.

The majority of the people squealing with glee over the introduction to Swift seem to be the sort of people I wouldn't care to work with. If a bit of syntax puts you off so much, lord help you when a truly new paradigm hits.

Swift looks to have some nice features, but it seems to be missing the low level access to the runtime that advanced developers can use like default message handlers (forwardInvocation:/doesNotUnderstand:/methodForSelector: kinds of stuff) and the ability to fiddle method dicts at runtime which can be very useful for intercepting strange errors and unexpected code paths.

So, yes, I do LOVE Objective-C. It is my second favorite language to work in after Smalltalk and to those claiming that Swift will help them move over from Android because it less verbose - lets remember Java is the most boilerplate per capability language I've seen since COBOL. I don't know what those people are talking about.

</comment></comment></comment></comment><comment><USER5> I just skimmed the tour, and my impression is: Swift is a compiled, Objective-C compatible Javascript-alike with an ObjC-like object model, generics, and string interpolation. No exceptions. Based on LLVM and appears to inherit the same data structures as Cocoa apps (Dictionaries, Arrays, &c).

It feels very lightweight, sort of like an analog to what Javascript is in a browser.

<comment><USER12> I think it uses the Objective-C runtime directly, so it has access to all the frameworks and Swift classes can be loaded into Objective-C projects as well.

There are a few other languages that do this with the Obj-C runtime, for example a Lisp variant called Nu[0].

[0] [http://programming.nu/](http://programming.nu/)

<comment><USER13> There's a Ruby implementation by a former Apple employee that does this as well: [http://www.rubymotion.com/](http://www.rubymotion.com/)

<comment><USER14> Unfortunately it requires a $200 up front investment before you can even toy with the language. RubyMotion was my first thought when I saw the code happening on the keynote, but at least this will be free with the OS.

</comment></comment></comment></comment><comment><USER15> "The company says that Swift apps are significantly faster than Objective-C apps, outperforming them by over 93x."

With a graph showing ObjC at 127x faster than Python, Swift 220x faster than Python.

Thus the conclusion is 220 - 127, Swift is 93x faster than ObjC.

Someone needs to resit their GCSEs.

<comment><USER16> "93x faster" sounds roughly like a 46.5x improvement in marketing.

<comment><USER17> It's not only possible, it's even not uncommon for a C programmer to get a 90X improvement in speed _in their own C program._ If you have naive memory management, or incorrectly implemented concurrency or parallelism, you can easily lose 2 orders of magnitude speed.

<comment><USER18> This. In my case a 1Mbyte memcpy in the middle of a loop this morning. Enough to blow the CPU cache out of the water...

300x improvement instantly by moving it out of the loop.

<comment><USER19> Are you sure it wasn't just because you were then no longer doing a large memcpy repeatedly?

<comment><USER18> Yes it was entirely covered by that :)

I think it was covered by "naive memory management" and "shitty outsourcing". I'm paid to fix their stuff.

<comment><USER19> If the problem was just the time taken to do a 1MB copy inside a loop, why did you say the problem was clearing the CPU caches?

<comment><USER18> Because the CPU has 32k of cache in this case (ARM) so the memcpy was evicting the entire cache several times in the loop as a side effect of doing the work. The actual function of the loop had good cache locality as the data was 6 stack vars totalling about 8k.

<comment><USER19> So? Copying a megabyte is a really expensive thing to do inside a loop, even ignoring caches. (A full speed memcpy would take 40 microseconds, based on a memory bandwidth of 24 GB/s, which is a long time.)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Enumerations (from: [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Enumerations.html#//apple_ref/doc/uid/TP40014097-CH12-XID_185)):

Unlike C and Objective-C, Swift enumeration members are not assigned a default integer value when they are created. In the CompassPoints example above, North, South, East and West do not implicitly equal 0, 1, 2 and 3. Instead, the different enumeration members are fully-fledged values in their own right, with an explicitly-defined type of CompassPoint.

+100 for that. This will help developer avoid whole class of bugs.

Enumerations also support associated values. Enums in .NET are very poorly defined. Looks like Swift got it right.

<comment><USER21> Indeed. Luckily C++11 took care of the issue on the C++ side.

[http://en.wikipedia.org/wiki/C++11#Strongly_typed_enumeratio...](http://en.wikipedia.org/wiki/C++11#Strongly_typed_enumerations)

<comment><USER22> Do Swift's enumerations allow recursive definitions?

</comment></comment></comment><comment><USER23> I find it a bit sad that with all of the languages that already exist, Apple found it necessary to invent a completely new one -- and then make it proprietary. Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.)

Heck, they could have bought RubyMotion and made Ruby the high-level language of choice for development.

I realize that Apple has a long tradition of NIH ("not invented here"), and in many cases, it suits them, and their users, quite well. But there are so many languages out there already that it seems like a waste for Apple to create a new one. Just the overhead of developing the language, nurturing its ecosystem, and ensuring compatibility seems like it'll cost more time and money than would have been necessary if they had gone with an existing language.

<comment><USER24> > _Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or > Scala? (Yes, I realize that the latter two run on the JVM, which would have > been problematic in other ways.) Heck, they could have bought RubyMotion and > made Ruby the high-level language of choice for development._

Because OBVIOUSLY none of them solve the problems they wanted to solve (interoperabillity with Objective-C, fast, native, IDE integration, etc. Including RubyMotion which is a half-arsed implementation.

<comment><USER25> I'm not sure if you're kidding or not.

IDE integration for a new language? They wrote it themselves. Do you think it would have been harder to integrate an existing language? Fast & native also also trivially solvable.

I don't know about interop with Objective-C, that's probably the hardest part from your list.

But complaining about IDE integration when they're also the creators of the IDE is... silly...

<comment><USER26> I see that you don't really understand what's needed for real IDE integration. Please, understand one of the main reasons of Apple creating Clang... (hint: because the GCC guys wouldn't take their patches to improve Objc-C & add facilities for IDE integration fast enough)

Clang was easier to integrate with an IDE than GCC, and I strongly believe (after seeing what apple showed yesterday) that swift integration is even simpler.

( They must have made a new LLVM front-end to embrace IDEs equally or better than Clang )

So no, it's not silly to try to design better to have a better integration with an IDE that you control too.

Cheers.

<comment><USER25> Well, that may be true for GCC but Ruby, Python & co are well integrated into many third party IDEs. So that point, at least, is moot.

<comment><USER24> "Ruby, Python & co are well integrated into many third party IDEs" perhaps you're not familiar with the level of IDE integration we're talking about here.

Most (if not all) IDE's Ruby and Python integration is BS.

We're talking about real AST-based highlighting and suggestions, auto fixes, autocomplete for all APIs available (AND your own custom modules), integration with the debugger and the build system, and in Swift's case also integration with the REPL, LighTable-style live-variables and Brett-Victor-inspired live coding environment.

This is not your grandfather's PyCharm.

</comment></comment></comment></comment></comment></comment><comment><USER27> > Looking for the Swift parallel scripting language? Please visit > [http://swift-lang.org](http://swift-lang.org)

Apple knew there was Swift-Lang, and still called this Swift. At least they link to it from their website!

<comment><USER28> Their icon even looks the same. It's also almost identical to the icon used by [http://swift.im](http://swift.im)

Sigh.

<comment><USER29> The Swift is a bird. It's unsurprising that the icons are of birds.

[http://en.m.wikipedia.org/wiki/Swift](http://en.m.wikipedia.org/wiki/Swift)

</comment></comment></comment><comment><USER30> Oh God, they just compared the speed of Objective C, Swift and... Python! It's nice to see Swift being faster than Objective C, etc., but what has Python got to do with coding native iOS/OS X apps? Of course it's going to fail at speed when compared to a static compiled language.

What a weird and pointless comparison, imo (I mean the inclusion of Python, seems so random to me).

<comment><USER17> _I mean the inclusion of Python, seems so random to me_

It's supposed to be a "mainstream" scripting language. Also, it's an easy way for them to get favorable numbers for their presentation.

<comment><USER31> On the Ars liveblog, I didn't see any mention of Swift support for other platforms. Are we going to see Swift on Linux and Windows as well?

<comment><USER32> I didn't either, but if not, my bet is that outside programmers will make an open source version (like Mono to C#).

<comment><USER33> According to one Apple developer who works on the project it will _likely_ be open sourced, though the developer says they don't know if that's true or not:

[http://forums.somethingawful.com/showthread.php?threadid=363...](http://forums.somethingawful.com/showthread.php?threadid=3639638#post430465353)

<comment><USER34> Could you post the message (or thread) somewhere? I think that post is paywalled.

<comment><USER33> Sure, sorry - I'm not sure which SA threads are free and which require payment. This is the relevant bit:

"Is this under NDA?

No.

Is this open source?

Not yet. It probably will be, but I can't make promises. Right now, our repository still has a lot of history that we don't want to make public, and we have a lot of work to do before we release."

<comment><USER34> Thanks.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> First question that comes to mind: how open is this language?

(I can't find any references to it)

<comment><USER36> Extremely closed, at least at the moment. Can't even read the language reference without Apple products.

<comment><USER37> You can actually read the language reference with a "standard browser":

[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/)

<comment><USER38> Hmm, can't seem to change page in Chrome. In Firefox, it works slightly better but still doesn't really. I'm guessing it only works on Safari? How can they release a language and not have proper documentation that is accessible by anyone?

It'd be great if someone could get the book, convert it to PDF and post it online.

<comment><USER39> PDF - [https://www.dropbox.com/s/wkxqv1zcgrg28m4/The%20Swift%20Prog...](https://www.dropbox.com/s/wkxqv1zcgrg28m4/The%20Swift%20Programming%20Language.pdf)

<comment><USER40> "Apple Inc. Copyright © 2014 Apple Inc. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, electronic, photocopying, recording, or otherwise, without prior written permission of Apple Inc., with the following exceptions: Any person is hereby authorized to store documentation on a single computer or device for personal use only and to print copies of documentation for personal use provided that the documentation contains Apple's copyright notice."

</comment></comment></comment></comment></comment></comment><comment><USER41> 1) This looks much less intimidating than Obj-C, I may finally write an iOS app.

2) Hopefully this puts some pressure on Google to make Go on Android easy (although I'm a Java guy myself).

3) What about swift-lang ([http://webcache.googleusercontent.com/search?q=cache%3Aswift...](http://webcache.googleusercontent.com/search?q=cache%3Aswift- lang.org)). It has the same name and almost the same icon. Did they work with these people or just screw them?

<comment><USER42> Re: 3)...

Look at the bottom of the page. There's a link to the swift-lang site...from an Apple web property. That's probably more publicity than the swift-lang folks could have hoped for in a million years.

</comment></comment><comment><USER43> My first instinct was to be cautious about new languages from Apple - <USER2> was supposed to be something awesome until Apple cancelled it. But I only learned of the existence of Dylan years after it was cancelled. Looked awesome, but it was so niche I didn't want to spend time learning it.

So I took a moment to look at why Dylan was cancelled.[1] Veryin interesting stuff. What it came down to was:

        - Apple was in dire financial straits

        - Apple needed to axe all projects that didn't show commercial viability

        - At the time, when Apple was transitioning to PowerPC, Dylan was 68K only, and needed another year or two to be ported

        - Most damning, the project was not finished - it wasn't even in the optimization stage.

None of these factors are in play here. So. My worries are assuaged. I do want to learn this, and it looks really easy to pick up so far.

I'm really curious now about two (unrelated) things:

1) is this good enough to build web apps with? 2) how would one manage the transition of an Obj-C based project to a Swift-based one? Assume I don't have the budget or manpower to perform a ground-up rewrite.

[1] [http://en.wikipedia.org/wiki/History_of_the_Dylan_programmin...](http://en.wikipedia.org/wiki/History_of_the_Dylan_programming_language#End_of_Dylan_as_commercial_product)

<comment><USER44> Based on my skimming of the Swift documentation, Dylan is a much nicer language (both in its original form and in its modern OpenDylan incarnation). That said, Swift just needs to improve on Objective C, which does not set the bar high.

</comment></comment><comment><USER45> We're writing a story for The Next Web on Swift. If anyone's interested in being interviewed for an article, can you flick me an email on email@example.com with brief answers to some or all of the following questions. I'd love to talk to anyone who's used Objective-C before and share your opinions/experience:

1) How does Apple releasing Swift make you feel as an Objective-C developer?

2) Are you excited to code using Swift?

3) What about Swift makes you most excited?

4) Do you worry about upskilling to Swift?

5) How do you think Swift will change the way you work?

6) What concerns do you have about swift?

Keen to understand how this impacts people and share that if you have time to talk to me :)

If you don't want to email, just reply here.

<comment><USER45> Thanks for all the responses - we ran this :) [http://thenextweb.com/apple/2014/06/03/developers-apples- swi...](http://thenextweb.com/apple/2014/06/03/developers-apples-swift-huge- potential/)

</comment></comment><comment><USER46> The live REPL is totally out of Bret Victor, very impressive.

<comment><USER47> Checkout Scala worksheets (Eclipse and IDEA) and LightTable too.

<comment><USER48> Yeah.. Because Scala doesn't have a metric ton of problems. AVOID!

<comment><USER49> Scala doesn't have a metric ton of problems. It has some problems, sure, but it has a lot of nice features as well.

<comment><USER50> Plus 'metric' must only accompany 'shitload' or other potty-mouthed quantifiers. Troll fail

</comment></comment></comment></comment></comment><comment><USER51> Here's the book for those without access to an iTunes account:

[http://kristofferr.com/files/The%20Swift%20Programming%20Lan...](http://kristofferr.com/files/The%20Swift%20Programming%20Language.epub)

<comment><USER52> thks :) , BTW I've used this firefox extension to view [https://addons.mozilla.org/en- US/firefox/addon/epubreader/](https://addons.mozilla.org/en- US/firefox/addon/epubreader/)

</comment></comment><comment><USER53> Swift reminded me of CoffeeScript a little, in a good sense (judging by what they showed during WWDC demo). Complexity and low-levelness of Objective-C is (was?) how I justified my reluctance to program for Apple devices, so I'll be looking forward to Swift.

The IDE they demoed looks very interesting on its own—it reminded me of Bret Victor's posts ([http://worrydream.com/LearnableProgramming/)](http://worrydream.com/LearnableProgramming/\)). Immediate interactive code visualization, quite impressive.

</comment><comment><USER54> We changed the url for this story from [http://thenextweb.com/apple/2014/06/02/apple-announces- swift...](http://thenextweb.com/apple/2014/06/02/apple-announces-swift-new- programming-language-ios). If we pick the wrong url, happy to change it again, so let us know. The goal is to have one discussion about each significant announcement, and have the best url for each.

</comment><comment><USER17> The demo from the WWDC keynote is quite impressive. Unfortunately, this site seems to have been slashdotted. (Basically, Swift is "Apple acquires their own LightTable.") It's touted as a language for parallelism. I'm curious about its concurrency primitives. Since distribution is shown as a top feature, I'm going to guess that it has an Erlang-like actor model.

Having ARC and not needing GC will end up being a big fundamental advantage for its parallelism story. (The problem with GC, is that one thread does work, then a GC thread comes along and possibly causes an additional cache miss.)

<comment><USER55> Swift doesn't seem to have anything to do with the parallel language at swift- lang.org. In any case, reference counting is disastrous for the parallelism story. GC thread coming along and causing an additional cache miss is way better than having to do atomic operations on reference counts all the time.

<comment><USER17> _Swift doesn 't seem to have anything to do with the parallel language at swift-lang.org._

Whoops. Should've corrected that when I copied the comment over.

 _In any case, reference counting is disastrous for the parallelism story. GC thread coming along and causing an additional cache miss is way better than having to do atomic operations on reference counts all the time._

Why are atomic reference counts necessary? You wouldn't generally need them with an Erlang-like Actor model or for special concurrency primitives like Go channels. (That is to say, you'd only need them in the special mechanisms.)

<comment><USER56> I'm not sure you can be Objective-C compatible without a shared heap. If you have a shared heap, you need atomic reference counting.

<comment><USER17> No. If you take the attitude that you're only covered if you use the concurrency primitives correctly, then you don't need atomic reference counting for everything. Basically, the programmer can use CSP to ensure that only one thread is messing around with any given section of the heap at a time, and the language implementers could say you're SOL if you do otherwise. (That probably isn't the Apple way, though.)

<comment><USER55> Swift uses the Obj-C runtime and interoperates with Obj-C code. Those languages assume a shared heap. If Swift modules didn't perform atomic reference counts, that would quite likely break Obj-C code operating on the same heap.

<comment><USER56> You'd break a _ton_ of Cocoa APIs too.

</comment></comment></comment></comment></comment></comment></comment><comment><USER57> Reading people compare Swift to other languages is pretty hilarious. OCaml.. Haskell.. CoffeeScript.. Ruby.. Go... Kotlin... JavaScript.. Scala... No one is saying it so I will: It looks like damn Java 8.

It is probably not a good sign that it can be immediately compared to every modern (and not so modern) language in existence.

<comment><USER58> And Swift seems to resemble another Apple language Dylan, which was based on Scheme/Lisp. All languages since the are in trouble!

I really like that it is incorporating good parts of many, more terse languages. Nothing wrong with selectively absorbing good ideas.

But a huge part is the interactive nature. I dabbled in Smalltalk some years ago and have been annoyed at compiled languages ever since, resorting to things like [http://injectionforxcode.com](http://injectionforxcode.com) to gain some of that back (on iOS).

Having a live environment can only be appreciated once it has been taken away. I think developing for Apple devices might just become one of the more programming pleasant experiences.

<comment><USER59> It does look a bit like Dylan. I wonder if it has more than a passing resemblance. Also I wonder if they are doing SBCL real time compelling.

</comment></comment></comment><comment><USER60> I really hope this language is going to become an open standard quickly. Here's hoping the language design is not too tightly coupled to the OS APIs.

<comment><USER61> This is going to be as open as objective-C. (Whether objective-C is open is left as an exercise for the reader.)

</comment></comment><comment><USER62> One thing I'm very interesting in knowing is how this affects the whole 'hybrid/web app' space.

Many web developers (like myself) have used Phonegap/Cordova in conjunction with tools like the Ionic Framework for our apps, primarily due to the nearly esoteric (for some of us) nature of Obj-C, but Swift almost looks like JS, which certainly has motivated me to learn it and use it in future apps.

I wonder if the aforementioned tools will lose market share because of that. Let's see.

<comment><USER63> (disclaimer: Ionic creator here): I think Swift will definitely get more people building iOS apps. But we still see a ton of demand from Ionic devs for Android support (perhaps more than iOS!), so unless the world moves 100% to iOS we think Ionic will still be incredibly important.

</comment></comment><comment><USER64> I found the notion of "Optionals" surprising and a bit hard to handle at first. In Objective C it was really easy to lazily allow values to be nil and still do things on them, so it's a bit of a departure.

Thinking about it a bit longer, is it because of the clear distinction between non nullable values ans optionals that the compiler can optimise the code so much more ? (I am thinking about the xx times faster than Objective C claims)

<comment><USER61> This might increase performance, but I'm pretty sure it's mostly there for safety. It forces the programmer to check for nil. It's like Haskell's "maybe" type.

<comment><USER65> Or Scala's Option or Java 8's new Optional ([http://docs.oracle.com/javase/8/docs/api/java/util/Optional....](http://docs.oracle.com/javase/8/docs/api/java/util/Optional.html))

</comment></comment></comment><comment><USER66> I'm interested to see the license under which Swift is released but it isn't mentioned anywhere. Is it under EULA or released under some open source license ?

<comment><USER67> Licensing is specified in the language specification document:

> No licenses, express or implied, are granted with respect to any of the > technology described in this document. Apple retains all intellectual > property rights associated with the technology described in this document. > This document is intended to assist _application developers to develop > applications only for Apple-branded products_.

It is pretty closed, if you ask me. Legally binding a language to a specific brand of product is a new low.

</comment></comment><comment><USER68> My thoughts while browsing the site:

\- function-level type inference much like Rust

\- no constness in the type-system (I like it)

\- class are reference types, structs are values types, much like D and C#

\- runtime dispacthed OO interfaces called "protocols". Blend the difference between runtime or compile-time polymorphism. Classes, structs and enums can implement a protocol. Available as first class runtime values, so the protocol dispatch will be slow like in Golang.

\- enumerations are much like Ocaml ADT, can be parameterized by a tuple of values, value types, recursive definitions (nice)

\- worrying focus on properties.

\- strange closure syntax

\- optional chaining, another anti-feature in my eyes

\- normal arithmetic operator throws a trap on integer overflow (!). This must be incredibly slow.

\- looks like Array is a fat slice to a reference-counted array

\- operator overloading is in, supercharged with custom operators, custom precedence (!?)

\- builtin tuples syntax

\- break with C integer promotion, like Rust.

\- no pointers

\- convenience is a keyword!

\- no exceptions (!)

\- unsigned integers: check

\- type inference is "bidirectional by expression or statement"

\- classes have deterministic destructors, structs have no destructors

\- It seems the only RAII source is through RC and classes.

\- no single root class

Make your own opinion.

<comment><USER69> Trap on Overflow is not that expensive: [http://www.sei.cmu.edu/reports/10tn008.pdf](http://www.sei.cmu.edu/reports/10tn008.pdf)

I am thrilled they did this. Implicit Overflow is the stupidest shit I know that everyone takes for granted.

Also with CPU support it could be free, and adds negligible complexity to the silicon.

<comment><USER70> The part of that paper that says how expensive Trap on Overflow is:

> At the `-02` optimization level, our compiler prototype showed only a 5.58% > slowdown when running the SPECINT2006 macro-benchmark. Although that > percentage represents the worst-case performance for AIR integers (because > no optimizations were performed), it is still low enough for typical > applications to enable this feature in deployed systems.

</comment></comment></comment><comment><USER71> 500+ comments and the term asynchronous does not appear once. It is a platform pain point, several languages have baked in support for async scenarios and Apple comes up with a whole new language, ignores it and a forum full of language geeks talks about it and no one points out it is missing.

<comment><USER72> Haha, I was searching for "async" and "await" keyword and only your post mentioned it

</comment></comment><comment><USER73> I don't have access to a machine with the new Xcode yet, but reading the book in iBooks, I found:

        NOTE

        For the best experience, open this chapter as a playground in Xcode.
        Playgrounds allow you to edit the code listings and see the result immediately.

Downloading gives me [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.playground.zip), a zip file with about 50 html files, a .css, about 40 .swift files and two files Results.playgrounddata and contents.xcplayground

Does that mean that playgrounds can be used for literate programming?

</comment><comment><USER74> Swift has also pattern matching which I think is really awesome.

<comment><USER75> Yes. They even have ranges in the patterns inside tuples. Not sure if any other language has that particular syntax.

<comment><USER76> F# has that. And also allows you to define your own constructors to pattern match on anything you want.

</comment></comment></comment><comment><USER77> There's one thing that bothers me about Swift, and I feel like I must not be getting it. For the most part it looks like a very well-designed language, and the choices they made are extremely pragmatic. But the way collection mutability is determined seems positively insane. You can't have a mutable reference to an immutable array, or vice-versa. I don't get the reasoning behind that.

<comment><USER34> I can't check it, but i presume you can do something like Rust and redefine immutable variables.

</comment></comment><comment><USER78> I'm a bit surprised by this move. I see that there are some advantages to this new language, but Objective-C is not as unapproachable as the unwashed masses make it out to be.

If Apple wanted to add official support for a new language I would think it would have been a better move to use something that already has an established following and could potentially attract new developers over. Something like Ruby/Python/Lua would seem to fit the bill nicely.

We've already seen Ruby can be done successfully on Mac with MacRuby and RubyMotion, but it nevers get full support from Apple.

Adding an additional programming language that binds me only to Mac platforms doesn't give me a whole lot of incentive.

</comment><comment><USER79> Ok, what about runtime support for older devices/iOS versions? They didn't say anything about it.

<comment> k-mcgrady They said that they were accepting apps built with Swift for iOS 8 and OSX 10.10 so sounds like it won't work with older OS version. They weren't all that specific about it though so I could be wrong.

<comment><USER80> New language runs on Obj-C runtime. Maybe apps written in Swift can run smoothly on existing OS.

</comment></comment></comment><comment><USER81> What i don't really see in the docs is how to calls to objective-c methods are sorted out. For instance, if I have an objective-c class with a method

        -(void)addNumber:(NSNumber*)num withString:(NSString*)str;

How is this called in swift? Is it

        myobj.addNumber(42, withString:"Hello World")?

<comment><USER82> There is a section in the docs about it. Similar to what you propose. [https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithObjective- CAPIs.html#//apple_ref/doc/uid/TP40014216-CH4)

<comment><USER81>
        UIColor *color = [UIColor colorWithRed:0.5 green:0.0 blue:0.5 alpha:1.0];

        let color = UIColor(red: 0.5, green: 0.0, blue: 0.5, alpha: 1.0)

Wow, this just brings up more questions, is the compiler removing the "colorWith" semantics or do you write your own translator?

<comment><USER83> The docs definitely indicate that some magic is occurring but they don't say exactly how. Perhaps If the first parameter contains the word "With"?

They do explicitly state that initializers will get "init" and "initWith" stripped off and whatever follows becomes the first parameter. The fact that "colorWithRed" is translated to "red" might indicate that it is looking for the keyword "With"

</comment></comment></comment></comment><comment><USER84> Somebody leak this manual please for the love of everything that is holy

... well I meant put it somewhere I could download from my Debian

</comment><comment><USER85> Looks like they've learned a lot from Haskell (but with none of the parts of Haskell that force you to construct things purely).

Looking forward to the Lambda the Ultimate discussions on this new language.

</comment><comment><USER86> Can anybody find a link to the Swift guide that they mentioned in Keynote? All I see is Taylor Swift books.

<comment><USER87> LOL

</comment></comment><comment><USER88> A lot of commenters here are asking whether it will be open sourced, I'm curious, specific to those who think it should be open sourced: why? I'm not really curious about the philosophical reasons, but really the practical ones. How would Swift being open source help you as a developer? It's clearly targeted at iOS and Mac OS X, so does this mean you won't write Mac OS X or iOS apps if it's not open source, or did you hope that you could write Swift code on other platforms?

<comment><USER89> Two big ones off the top of my head:

        - Porting to other platforms/community implementations (think Mono)
        - Developer input: being able to submit bugs, influence or even just *watch* the trajectory of the language, get a deeper understanding of how various components are really implemented

</comment></comment><comment><USER90> Automatic Reference Counting

Swift uses Automatic Reference Counting (ARC) to track and manage your app's memory usage. In most cases, this means that memory management "just works" in Swift, and you do not need to think about memory management yourself. ARC automatically frees up the memory used by class instances when those instances are no longer needed."

Excerpt From: Apple Inc. "The Swift Programming Language." iBooks. [https://itun.es/il/jEUH0.l](https://itun.es/il/jEUH0.l)

<comment><USER91> It "automatically" works until it doesn't. Pointer semantic is the first thing i've looked, and unsurprisingly, they still have the "weak / strong" pointer semantic.

You can still point to nil pointers and crash the program because of it, and you can still have retain cycles which creates memory leaks.

That language really looks more of trying to make good compromise rather than create a revolution or a breakthrough. In a way, that feels like a much safer choice.

</comment></comment><comment><USER92> Hopefully there are some of Bret Victor's "lost" ideas in there: [http://worrydream.com/Apple/](http://worrydream.com/Apple/)

</comment><comment><USER93> The documents for ios 8 show all examples in objective-c. Can't wait for them to be updated to swift. I'd love to start with 'getting started' and work my way through rest of the docs. I'm a programmer but could never stomach objective-c.

<comment><USER94> Some of the new docs I've seen let you select Objective-C, Swift, or both.

<comment><USER93> Doesn't look like "Start Developing iOS Apps Today" has an option to switch to Swift.

</comment></comment></comment><comment><USER95> [https://developer.apple.com/swift/](https://developer.apple.com/swift/)

</comment><comment><USER96> Just glanced thru the Swift book in about 3 hours. Conclusion: all your programming language are belong to Swift, mostly stolen good ideas, some innovations, a few gripes.

I can say Swift takes inspiration and improves on at least these languages:

C:

typealias

struct

control structures

labeled statements AKA gotos

varargs

C++:

default arguments

class instance construction syntax

// comment

superclass, implementing protocol declaration syntax

semi-virtual class init, deinit

Go:

No parentheses around the condition part of control statements

Unicode identifiers

shorthand for signed and unsigned integer types U?Int(8|16|32|64)

C#:

in-out params

properties

subscript access of class member values

Objective-C:

ARC

protocols

extensions

param names as method names

willSet/didSet

nil?

Java:

enum

@final

super keyword

override method keyword

Scala:

Local type-inference, blend of an ML flavored FP with OOP without the noise and believe it or not, even more powerful in specifying generic type constraints. No stupid JVM type erasures either so you can actually create an instance of a generic type, just like C++ templates.

Self:

self

Python:

for i in enumerate(seq)

for key, value in dictionary

Type(value) explicit type conversion syntax

No public/private/protected class member access modifier bullshit

Array literals, dictionary is also like Python but use [] instead of {}

Ruby:

0..100, 100_000

Lisp:

closures

Scheme, Coffeescript:

? optional type modifier

Bash:

$0, $1... inside short callback closures

Innovations

\</comment><comment></comment><comment>---

break-less switch, optional fall-thru, comma as multiple case, case can be any value of any type, condition or a type constraint for pattern matching, supports method call shorthand

generic type constraint queries

overflow operators

@prefix, @postfix, @infix, @assignment modifiers for operator overloading Trailing closure as partial function application

Gripes

\</comment><comment>

Seems like array[4..6] is even more useless than Javascript's Array#slice, and a far cry from Python's slices.

No set literals and list/set/dict comprehension.

Nothing for concurrency???? No yield, no generators, no channels, not even the synchronized keyword.

There's no decorator or annotations, and Swift isn't Objective-C, what's with the odd-ball @ modifiers?

I don't see namespaces as mentioned in the WWDC slides, and goto is definitely still here so you might just write another gotofail.

Looks like Swift is Apple's answer to Go, Rust, Scala, Java, PyObjC/RubyMotion, Unity, Xamarin and all these HTML5 + JS/Phonegap people. I'll definitely pay attention to Swift. If the performance results hold up, Swift + iOS8 will definitely leave Android's ancient Java 5 crap way out in the dust.

[https://itunes.apple.com/us/book/swift-programming- language/...](https://itunes.apple.com/us/book/swift-programming- language/id881256329?mt=11)

<comment><USER97> Concurrency will probably be handled using Grand Central Dispatch's[0] queues.

[0] [http://en.wikipedia.org/wiki/Grand_Central_Dispatch](http://en.wikipedia.org/wiki/Grand_Central_Dispatch)

<comment><USER98> You're right. I can remember an example with something like:

dispatch_async(queue) { /* code here */}

That's an idiomatic adaptation to dispatch_async to support closures. I guess this internally might be converted to a block.

</comment></comment></comment><comment><USER99> The `enum` part of the language seems to be Haskellish algebraic types - <USER3> you can have enum "cases" with parameters in addition to just named enumerations .. and these enums can have methods. Cool!

<comment><USER100> This is a hidden killer feature

</comment></comment><comment><USER101> For those without iBook, here's an excerpt from "The Swift Programming Language": [http://pastebin.com/xsr401gt](http://pastebin.com/xsr401gt)

<comment><USER102> It works in Calibre, provided you can get your hands on the epub file in some way...

<comment><USER103> I got it from Apple's ebook store. It showed up in ~/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books

</comment></comment></comment><comment><USER104> Unicode variables, I love it:

let 🐶🐮 = "dogcow"

Moof!

<comment><USER105> You can do this in C# (and presumably other languages). I've seen people using Greek symbols in mathy code before. It's kind of fun.

<comment><USER106> It's fun once. It's impractical for someone editing the code later though, I don't want to have to look up the unicode character each time I want to remember it, and I don't want to have to copy and paste it either, it's better to stick with the characters available on a keyboard.

<comment><USER14> OS X handles some of this by assigning mnemonics to keyboard keys with the meta key (on mac keyboards, Option, or the "windows" key on the standard layout) held down.

For instance, the registered trademark symbol ® is just option+r. ∑ is option-w. Diacritics are two-stroke combinations, to get é, you'd type option-e, which puts the ´ on the screen, and then type the e to complete the character.

Some of them definitely make more sense than others. ∑ looks like a sideways 'W", the trademark symbol is just a circled r, and the diacritic marks fit the character you'd commonly associate them with. (Guess what letter you hit to get ¨ over a letter?)

Beats copy/pasting out of character map, anyways!

<comment><USER73> _" OS X handles some of this by assigning mnemonics to keyboard trademark symbol ® is just option+r. ∑ is option-w."_

And, after they ran out of mnemonics, they sprinkled the rest of the characters on the keyboard (almost; I think they tried hard to keep things memorable, but some combinations are just plain of the "if you don't know it, you 'll never guess". The Apple logo is on the k key, for instance (IIRC). Mnemonic? MaKintosh?)

 _" Diacritics are two-stroke combinations, to get é, you'd type option-e, which puts the ´ on the screen, and then type the e to complete the character."_

That's the old way. Recent OS X has 'hold down the e key, a menu pops up, click the desired variant or type the digit shown next to it'.

<comment><USER14> Ah neat, I wasn't aware of this. Every mac I use has the press-and-hold mechanic disabled to support a higher repeat rate. I might have to go back and play with it some more.

</comment></comment></comment></comment></comment></comment><comment><USER107> As someone who's biggest hurdle was the syntax of Objective-C, this is absolutely massive personally. Just the other day, me and my friend was discussing how hard Objective-C is to properly learn. Of course, the jury is still out on Swift until I read further on it, but it can't possibly be worse then Objective-C.

Looking forward to it.

</comment><comment><USER108> "When Apple announced Swift at WWDC, it got the largest cheer out of the developer audience than any other single feature." :D Sigh of relief!

</comment><comment><USER109> HR departments around the world are going to have to update their mobile dev job postings to include "3+ years of experience with Swift."

</comment><comment><USER110> In the playground REPL, am I missing an easy way to display errors as they happen?

It seems any error messages aren't visible by default. Xcode shows a red "!" disc next to the line, and that's it.

The usual shortcuts for "Jump to next/previous issue" are disabled. Opening the issues tab with command-4 works, but it's empty. Apparently I have to mouse over and click on the tiny red disc to see any error message at all, and then it displays as text that can't be selected or copied.

EDIT: ctrl-command-M turns "Show all issues" on or off. It seems to be a little buggy, which may be why it's off by default. Hopefully we'll get the ability to copy the error text in the next refresh.

</comment><comment><USER62> Now, if Go was implemented on Android, I'd probably develop a _lot_ more for mobile.

<comment><USER111> Look into Kotlin for Android development. It's a nice-looking language.

</comment></comment><comment><USER112> Anyone know how Swift might achieve its claimed speedup vs. Objective-C? I can't see how it could get the advertised numbers without method inlining, which appears to be incompatible with the dynamic object model that it inherits from Objective-C

<comment><USER113> Why would method inlining be incompatible with dynamic dispatch?

<comment><USER112> I was thinking more about runtime method replacement.

</comment></comment></comment><comment><USER114> I'm reading the manual and liking nearly everything. But then I stumble across:

> Alternatively, remove a key-value pair from a dictionary with the > removeValueForKey method.

Is that the day where an Objective-C got to choose method names? Why not dict.delete() or similar?

<comment><USER115> You mean an API than you can actually read and understand? How dare them take your 1970s 80-char display away from you!

<comment><USER114> You mean a methodNameThatOverlyExplainsEverythingEvenThoughTheContextMakesItClear()?

</comment></comment></comment><comment><USER116> It seems perfectly serviceable, but I have to admit that my reflex response on opening the page was 'Oh god, _another_ language?'

I can't tell if Apple is proposing this as a great new language everyone should use, or whether it's only intended for developers using Apple hardware and so represents a sort of lock-in strategy. I don't have an opinion on the language itself - it seems to have several neat features that make it easier/safer than competing languages like js, but presumably there are a few shortcomings as well.

</comment><comment><USER117> So, I picked up Objective-C a few weeks ago, and I've been struggling (only coming from a Python background, with only the CS-knowledge I've picked up along the way). I just figured it would be fun to be able to make some apps. What would your advice be? Stick with Objective C, or switch over to learning Swift? Swift looks a lot more friendly, but I don't want to sell myself short. I'm also thinking big picture, where learning Obj-C might eventually be helpful in learning other languages.

<comment><USER118> I know neither.

I'd skip Objective-C and learn Swift to actually make a thing.

If you want general language knowledge, a really hairy production language and toolset isn't the place to look. You'll be fighting with lots of incidental stuff along the way.

Learning different kinds of languages will help you learn more languages.

</comment></comment><comment><USER119> It is exciting, the language is full of modern stuff... This is what I catch at a glance of the book:

\- Optionals (Java's @Nullable)

\- Tupples

\- Functions as first class citizens

\- let vs var (immutable vs mutable)

\- Operators are functions

\- Closures

\- Extensions (Adding things to an existing class)

\- Value object (struct - are passed by value -- and so are Strings!!! )

\- Reference Objects (class)

\- Generics (lets hope it will be better than Java's version)

\- External Parameters ??

\- @final keyword (to prevent overrides - like Java's final)

It kinda looks like C# meets Ruby meets the let keyword Very complex...

And More

\- object reference operator === and !==

\- typealias (~ typdef)

\- Optional Binding (if let x = y.f() { } else {}

\- for-in loops (for i in 0...count)

\- The default behavior of switch is not to fallthrough

</comment><comment><USER120> A lot of the syntax is incredibly similar to rust.

<comment><USER101> Yes, but Swift looks much cleaner thanks to ARC memory management. I wish Rust has something similar, all those sigils make it messy.

<comment><USER56> What sigils? All Rust has is & now.

Using ARC removes control from the programmer and has a significant runtime overhead (atomic reference counts), which violates Rust's zero-overhead principle. What Swift works well when you need deep Objective-C integration, of course.

<comment><USER121> Could "'" count as type-parameter sigil for lifetimes? It could at least look like a sigil on a first look.

</comment></comment></comment></comment><comment><USER122> I really wish we could play with it, without having to be a paid member.

It's crazy how Apple is always so scared to release dev tools, at the end it will be out-there on bittorrent anyway...

<comment><USER123> Visual Studio isn't free in that regard either. What exactly are you comparing this release to?

<comment><USER76> VS has non-paid versions. And C# and F# compilers are open source.

<comment><USER82> Yes, but you need Windows and a Windows PC to run them. I guess you could get Linux for C# and F# but you still need to buy a PC.

<comment><USER124> How are you doing development without a non-mobile OS? But I imagine [http://www.tryfsharp.org/](http://www.tryfsharp.org/) works even for mobile.

</comment></comment></comment></comment></comment><comment><USER125> Swift is designed to make many common C and Objective-C errors less likely, but at least one class of bugs could be ascendant: off-by-one errors in ranges. Swift's ".." and "..." range operators are _reversed_ compared to Ruby and CoffeeScript.

Swift's way is arguably more sensible: the longer operator makes a longer range. But switching the way two similar-looking operators work, as opposed to at least two other languages popular with the target audience, is bound to lead to errors as programmers switch contexts.

Just the fact of having the two operators in the language together is dangerous, since they look similar and switching them will lead to weird bugs instead of immediate compile-time or runtime errors. Switching their meanings makes this more pernicious.

Time to prime our eyeballs to look out for this one.

[1] Swift book: "Use .. to make a range that omits its upper value, and use ... to make a range that includes both values."

Excerpt From: Apple Inc. "The Swift Programming Language." iBooks. [https://itun.es/us/jEUH0.l](https://itun.es/us/jEUH0.l)

[2] Ruby: "Ranges constructed using .. run from the beginning to the end inclusively. Those created using ... exclude the end value." [[http://www.ruby-doc.org/core-2.1.2/Range.html](http://www.ruby- doc.org/core-2.1.2/Range.html)]

[3] CoffeeScript: "With two dots (3..6), the range is inclusive (3, 4, 5, 6); with three dots (3...6), the range excludes the end (3, 4, 5)".

</comment><comment><USER126> So Google...still not going to push Go to Android, already?

<comment><USER127> It's more likely, they will push Dart as next Android lang

</comment></comment><comment><USER128> Swift looks promising and looks like a step in the right direction. However, looking at the reference and everything, I fail to find an answer to this question. Does the concept of private members (methods and variables) in Swift's object system not exist? It looks like every single variable is exposed fully without any way to prevent it from being so.

</comment><comment><USER91> One question to the audience : i've had a look at the swift iBook and noticed that dictionary are strongly typed. Which is great in a way, but now i wonder :

how would you create a json deserializer ( which conveniently deserialized into NSArray and NSDictionnary of anything ) ? I didn't see any "object" or "id" type equivalent.

<comment><USER129> There is a special type called AnyObject that represents Objective-C id values

</comment></comment><comment><USER130> There will be the Swift language developer center at [http://swiftlang.eu](http://swiftlang.eu) \- right now it redirects to the Apple website.

The Swift eBook is available at [http://book.swiftlang.eu](http://book.swiftlang.eu)

What would you like to see there beyond reference docs, guides and examples?

</comment><comment><USER131> At a glance, it looks like ScalaScript

</comment><comment><USER132> There is the official Swift Book: The Swift Programming Language by Apple Inc.

Book Link: [https://itunes.apple.com/us/book/the-swift-programming- langu...](https://itunes.apple.com/us/book/the-swift-programming- language/id881256329?mt=11)

Swift is a new programming language for creating iOS and OS X apps.

Swift builds on the best of C and Objective-C, without the constraints of C compatibility. Swift adopts safe programming patterns and adds modern features to make programming easier, more flexible, and more fun. Swift's clean slate, backed by the mature and much-loved Cocoa and Cocoa Touch frameworks, is an opportunity to reimagine how software development works.

This book provides:

\- A tour of the language.

\- A detailed guide delving into each language feature.

\- A formal reference for the language.

Hope it helps.

</comment><comment><USER133> Perhaps it was just for the benchmark, but it seemed ambitious that they're testing encryption algorithms with it already. Does anyone know if Swift, by design, could help avoid issues like they've had recently with Secure Transport?

</comment><comment><USER134> Inferred types, first class functions, closures, great speed -- this looks very promising.

</comment><comment><USER135> Is anyone getting the vibe that swift is golang for writing Cocoa apps, or is it just me?

<comment><USER136> To me it feels more like a kind of Vala for Cocoa.

</comment></comment><comment><USER84> www.mcs.anl.gov/papers/P1818.pdf

Swift: a language for parallel scripting, 2011, mostly from University of Chicago

Anyone knows if it's related?

<comment><USER84> Right yeah it's completely unrelated. My bad.

</comment></comment><comment><USER137> Anybody have any reference to language docs?

<comment><USER138> It just became available in the US ibook store

[https://itunes.apple.com/us/book/swift-programming- language/...](https://itunes.apple.com/us/book/swift-programming- language/id881256329?mt=11)

<comment><USER139> And if anyone else accidentally tried to get it in the UK store first follow these instructions to get the use store back:[https://discussions.apple.com/message/22116986#22116986](https://discussions.apple.com/message/22116986#22116986)

basically you just need to scroll to the bottom of the bookstore front page and touch your username to logout and then log back in.

</comment></comment></comment><comment><USER140> Here are some coding styles I found for Swift: [http://codingstyleguide.com/lang/23/swift](http://codingstyleguide.com/lang/23/swift)

</comment><comment><USER141> Someone bought swiftcasts.com today ... [http://whois.domaintools.com/swiftcasts.com](http://whois.domaintools.com/swiftcasts.com)

</comment><comment><USER142> This is a fascinating development. I wonder how Swift will impact the many cross-platform mobile frameworks. Objective-C was a big barrier for many beginners and small companies and a free and easier development language provided by Apple and supported with good docs and third-party tutorials will likely command a good amount of mind-share. It's going to be an interesting few months in the mobile development world.

</comment><comment><USER143> So, they have the weird syntax the MacRuby people were using. I really hate they removed the Smalltalk selector syntax and replaced it with the half- thingy.

</comment><comment><USER144> Any ideas on how easy it will be to slurp JSON with Swift?

<comment><USER145> Define easy?

`NSJSONSerialization` worked pretty well with iOS 5.x and above.

Not sure if you're looking direct JSON -> Object serialization.

<comment><USER144> Ah yes, that will do. Thanks!

</comment></comment></comment><comment><USER146> I'm assuming that there's no memory safety guarantee for Swift code that interacts with Objective C code. Can anyone shed any light on this?

</comment><comment><USER147> Did anybody find information regarding namespaces?

</comment><comment><USER148> Does this mean I can finally get around to porting my phonegap plugins over to iOS without having to dive deeply into Objective-c?

<comment><USER149> Swift looks quite similar to javascript - it may be fairly easy to port, I hope.

</comment></comment><comment><USER150> What kind of benchmark produced 220 times something faster than Python? My guess is that they did it on a mobile device and used an application like this: [https://itunes.apple.com/us/app/python-2.7-for- ios/id4857298...](https://itunes.apple.com/us/app/python-2.7-for- ios/id485729872?mt=8)

<comment><USER17> _What kind of benchmark produced 220 times something faster than Python?_

Python and Ruby are resource profligate dynamic languages in comparison to other dynamics langs like Lua and Smalltalk. If you are surprised that someone could come up with a benchmark that disadvantages Python by a factor of 200, then you have a lot of neat reading to look forward to in language implementation and Python internals. For some reason speed is easy for our reptilian brains to grasp at. _It 's not the be-all end-all of a language._

</comment></comment><comment><USER151> I wonder how many years, n, from now it takes for people to claim they have N > n years of experience with Swift on their CV.

<comment><USER152> Presumably 0, since there are already people who can legitimately claim multiple years of experience with Swift.

</comment></comment><comment> eden-san I am surprised noone mentioned Erlang!

Tuples and pattern matching are the bread and butter in Erlang and deserve to be mentioned as one of the source of inspiration for the Swift language.

The '_' character used to ignore some values in loops/patterns was also taken from Erlang (for _ in array { ... }).

</comment><comment><USER133> Question: It sounds like the Xcode 6 beta is available on the dev center but I can't find it. Do you have to be a paying developer to have access to it, or does anyone know if it's going to be made available for free to (unpaid) registered developers?

<comment><USER153> I can't think of a reason why they wouldn't allow unpaid devs to play with Swift.

<comment><USER154> To get more devs to pay.

</comment></comment></comment><comment><USER155> Slightly disappointed that I won't be able to try it out yet, because I'm not a Mac Developer. I can't get the XCode 6 beta without it, so I'd have to cough up $99 to try a new language... It seems to me like that might hurt its adoption.

<comment><USER149> I think you should be able to get it when it's out of beta without the $99 thing. Also I have paid my $99 and have not been able to get it yet.

</comment></comment><comment><USER156> Noob here. I don't understand... so what happens to Objective-C? Why would you code an iOS app with one language instead of the other? Why would you use both? That just sounds like a pain. Is Swift the evolution of Objective-C or something?

</comment><comment><USER157> As a C# developer, I've felt familiar to this lanuage. I don't know why...

</comment><comment><USER158> One of the things I look for in a language right off the bat, as it's a sign that powerful features can be built as libraries later, is some type of reflection api. There appears to be none (though attributes seem cool).

</comment><comment><USER159> Do we know if enums can be recursive?

i.e.

enum BinaryTree = { case Leaf(Int) case Node(BinaryTree, BinaryTree) }

<comment><USER160> I saw somewhere else today that someone tried it and it crashed the compiler, so I guess not. The string "recur" doesn't even occure once in the iBook. It seem though that you might be able to use a combination of objects and enums to get that.

</comment></comment><comment><USER161> I'm super excited about Swift as Objective-C was always a barrier for me as I dislike it very much. This was the greatest news from Apple today, I hope to see compilers on other platforms as well soon.

</comment><comment><USER162> "innovative" "new" "concise" "expressive" "lightning-fast"

God, I love Apple. Now I just wish _real_ innovative languages could market themselves as efficient.

</comment><comment><USER163> Maybe I'll pickup iOS dev, do you still have to have an mac to dev?

<comment><USER164> Yes, you need a Mac, especially if you want to be able to use Xcode and Swift.

If you are short on money, you can try to buy a second hand iMac or a MacMini (just be sure it will support the next OS X version 10.10).

</comment></comment><comment><USER165> As someone who has written apps in Lua using Corona SDK. This is exciting. Syntax looks a lot like Lua/Ruby and we are not stuck using the watered down version of Lua that Corona provides.

</comment><comment><USER166> Now where to read some code examples, they may say its better but until I read some code I remain unconvinced (still anything sounds better than Objective-C)

</comment><comment><USER167> I just started learning Objective-C a week ago. Was almost finishing the Stanford iOS 7 course.

Coming from a Ruby background I couldn't be more surprised and excited!

</comment><comment><USER168> It looks pretty nice, I hope they didn't forget about concurrency and parallelism. I don't see anything talking about this in the iBook.

<comment><USER83> They link over to this site from the Apple page about Swift [http://swift- lang.org/](http://swift-lang.org/) \- I couldn't tell if they are the same thing or if Apple Swift is just based off of this..?

<comment><USER169> your trolling.

<comment><USER83> I actually was not, I didn't understand the relationship between the two languages. I see now that they are not related at all. By the way, it's "You're trolling"

</comment></comment></comment></comment><comment><USER170> So is swift an extension of c like obj-c is? In theory, can I have a program/app that uses swift, obj-c, and c syntax all in the same file?

<comment><USER171> Same project, not mixed in files.

</comment></comment><comment><USER172> No built in support for concurrency or parallelism :(

</comment><comment><USER173> It's closest relative is Kotlin, as far as I can see. It shares a lot of the same functionality, from the null-checking to generics, etc.

</comment><comment><USER174> As a detached Apple-related news follower, can some please update me: Is Swift going to become the new main development language for iOS?

<comment><USER175> If it's actually faster than Objective-C like Apple claims, then I'd bet on it, yeah.

<comment><USER176> Even if it's not faster, yeah. Most apps don't have any performance bottlenecks, and the ones that do can just drop down to Obj-C/C/C++

</comment></comment></comment><comment><USER177> As someone coming from Python and Java but always dissuaded by Objective C's menacing syntax, I am 100% behind the new change.

</comment><comment> ah- Any hints on how hard it is to call C libraries from within Swift? This might be a great way to quickly develop a native UI.

<comment><USER94> I dunno, but you could always call the C libraries from Objective-C, and call the Objective-C from Swift.

</comment></comment><comment><USER178> I hope some of the debugging UX will cross over to objC dev; my experience is that this is the weak point of the XCODE IDE.

</comment><comment><USER179> What is the advantage of "func funcName() -> returnType{ }" over "returnType funcName(){ }"?

<comment><USER180> When your function returns a function, it's cleaner.

func funcName() -> Int -> String { return { (i: Int) -> String in return i.toString() } }

</comment></comment><comment><USER181> Why do we have to wait with submitting apps that uses Swift until fall when Swift works with iOS 6 and iOS 7?

</comment><comment><USER182> I feel like I could do most of this stuff with lua...but I haven't touched lua on iOS in years.

</comment><comment><USER183> ObjC and its quirks was a major reason i never did Mac development. This sounds more interesting.

</comment><comment><USER184> Will it still cost me an Arm, a Leg, and my first born to obtain the dev tools and compile code?

<comment><USER88> The beta currently requires that you are a member of one of the Developer programs (iOS or Mac) which costs $99 per year.

Release versions of Xcode are freely available at no cost (except that you need a Mac)

</comment></comment><comment><USER185> Oh! Finally! swf files on iOS :-)

</comment><comment><USER82> Nested multiline comments. :-)

</comment><comment><USER82> Now I wish I knew of a tool to filter out HN comments older than x hours.

</comment><comment><USER186> I'm a learning addict. Has somebody tasted it and is this worth it?

</comment><comment><USER187> I like the "value binding" for switch statements with tuples.

</comment><comment><USER164> This is probably the biggest announcement from a developer perspective. Swift looks like a language in which you can code as fast as you code in languages like Ruby or Python, while having the speed and performance of a language like Objective-C.

</comment><comment><USER188> Swift was the biggest announcement today. Looking forward to it.

</comment><comment><USER189> Looks neat, but I'm disappointed that Apple didn't go with Ruby for their next-generation language. Things like MacRuby and Ruby Motion make it seem like that was a possibility, albeit a pretty distant one.

</comment><comment><USER190> [Book link]([https://itunes.apple.com/gb/book/swift-programming- language/...](https://itunes.apple.com/gb/book/swift-programming- language/id881256329?mt=11))

</comment><comment><USER139> Does anyone know when the new (beta) Xcode will come out?

<comment><USER139> Disregard: I wasn't signed in. You can download Xcode 6 now and test it out!

</comment></comment><comment><USER191> > you don't even need to type semi-colons.

But you still need to type curly braces. Which are utterly redundant with indentation, pain to type, brainless task that languages should take care of, and a source of bugs.

</comment><comment><USER192> [http://en.wikipedia.org/wiki/Society_for_Worldwide_Interbank...](http://en.wikipedia.org/wiki/Society_for_Worldwide_Interbank_Financial_Telecommunication)

</comment><comment><USER193> Can't find the link to download Xcode beta!

<comment><USER194> You have to be a developer but... [xcode6 link] [https://developer.apple.com/devcenter/mac/index.action](https://developer.apple.com/devcenter/mac/index.action)

Edit: You then have to click "OS X Yosemite Developer Preview". Then scroll down, it's at the bottom of the page

<comment><USER193> Ah, you have to pay to play!

</comment></comment></comment><comment><USER195> There are cool things in Swift, but I hope they just promote Javascript to a system language so that all platforms can go towards a single code base.

<comment><USER160> iPhone apps need to be more webscale and NoSQL compliant too. And what about event based? (Hmm...)

</comment></comment><comment><USER196> So is Swift a managed language or what?

<comment><USER197> It uses Automatic Reference Counting like Objective C. You must avoid strong reference cycles by declaring your fields weak and optional or unowned. It has deterministic deinit.

</comment></comment><comment><USER198> Anyone have any links or resources?

</comment><comment><USER199> Has some features from Lisp.

<comment><USER200> So does every language.

<comment><USER199> I was implying that a feature that is known to be in Lisp but not in most of the other languages. Such as Read–eval–print loop.

</comment></comment></comment><comment><USER199> Do they have a pdf book?

</comment><comment><USER201> Anyone else see quite a lot of Scala here?

<comment><USER198> Yup...

</comment></comment><comment><USER202> You appear to be advocating a new:

[ ] functional [X] imperative [X] object-oriented [X] procedural [X] stack- based

[ ] "multi-paradigm" [ ] lazy [ ] eager [X] statically-typed [ ] dynamically- typed

[ ] pure [X] impure [ ] non-hygienic [ ] visual [ ] beginner-friendly

[ ] non-programmer-friendly [ ] completely incomprehensible

programming language. Your language will not work. Here is why it will not work.

You appear to believe that:

[X] Syntax is what makes programming difficult

[ ] Garbage collection is free [ ] Computers have infinite memory

[ ] Nobody really needs:

        [X] concurrency  [ ] a REPL  [ ] debugger support  [ ] IDE support  [ ] I/O

        [X] to interact with code not written in your language

[ ] The entire world speaks 7-bit ASCII

[X] Scaling up to large software projects will be easy

[X] Convincing programmers to adopt a new language will be easy

[X] Convincing programmers to adopt a language-specific IDE will be easy

[ ] Programmers love writing lots of boilerplate

[ ] Specifying behaviors as "undefined" means that programmers won't rely on them

[ ] "Spooky action at a distance" makes programming more fun

Unfortunately, your language (has/lacks):

[ ] comprehensible syntax [ ] semicolons [ ] significant whitespace [ ] macros

[X] implicit type conversion [ ] explicit casting [ ] type inference

[ ] goto [ ] exceptions [ ] closures [X] tail recursion [ ] coroutines

[ ] reflection [X] subtyping [X] multiple inheritance [ ] operator overloading

[X] algebraic datatypes [ ] recursive types [ ] polymorphic types

[X] covariant array typing [ ] monads [ ] dependent types

[ ] infix operators [ ] nested comments [ ] multi-line strings [ ] regexes

[ ] call-by-value [ ] call-by-name [ ] call-by-reference [ ] call-cc

The following philosophical objections apply:

[ ] Programmers should not need to understand category theory to write "Hello, World!"

[ ] Programmers should not develop RSI from writing "Hello, World!"

[ ] The most significant program written in your language is its own compiler

[X] The most significant program written in your language isn't even its own compiler

[X] No language spec

[X] "The implementation is the spec"

       [X] The implementation is closed-source  [ ] covered by patents  [ ] not owned by you

[X] Your type system is unsound [ ] Your language cannot be unambiguously parsed

       [ ] a proof of same is attached

       [ ] invoking this proof crashes the compiler

[X] The name of your language makes it impossible to find on Google

[ ] Interpreted languages will never be as fast as C

[ ] Compiled languages will never be "extensible"

[ ] Writing a compiler that understands English is AI-complete

[ ] Your language relies on an optimization which has never been shown possible

[ ] There are less than 100 programmers on Earth smart enough to use your language

[ ] ____________________________ takes exponential time

[ ] ____________________________ is known to be undecidable

Your implementation has the following flaws:

[ ] CPUs do not work that way

[ ] RAM does not work that way

[ ] VMs do not work that way

[ ] Compilers do not work that way

[ ] Compilers cannot work that way

[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()

[ ] You require the compiler to be present at runtime

[ ] You require the language runtime to be present at compile-time

[ ] Your compiler errors are completely inscrutable

[ ] Dangerous behavior is only a warning

[ ] The compiler crashes if you look at it funny

[ ] The VM crashes if you look at it funny

[ ] You don't seem to understand basic optimization techniques

[ ] You don't seem to understand basic systems programming

[ ] You don't seem to understand pointers

[ ] You don't seem to understand functions

Additionally, your marketing has the following problems:

[X] Unsupported claims of increased productivity

[X] Unsupported claims of greater "ease of use"

[ ] Obviously rigged benchmarks

       [ ] Graphics, simulation, or crypto benchmarks where your code just calls

           handwritten assembly through your FFI

       [ ] String-processing benchmarks where you just call PCRE

       [ ] Matrix-math benchmarks where you just call BLAS

[ ] Noone really believes that your language is faster than:

        [ ] assembly  [ ] C  [ ] FORTRAN  [ ] Java  [ ] Ruby  [ ] Prolog

[ ] Rejection of orthodox programming-language theory without justification

[ ] Rejection of orthodox systems programming without justification

[ ] Rejection of orthodox algorithmic theory without justification

[ ] Rejection of basic computer science without justification

Taking the wider ecosystem into account, I would like to note that:

[ ] Your complex sample code would be one line in: _______________________

[ ] We already have an unsafe imperative language

[X] We already have a safe imperative OO language

[ ] We already have a safe statically-typed eager functional language

[ ] You have reinvented Lisp but worse

[ ] You have reinvented Javascript but worse

[X] You have reinvented Java but worse

[ ] You have reinvented C++ but worse

[ ] You have reinvented PHP but worse

[ ] You have reinvented PHP better, but that's still no justification

[ ] You have reinvented Brainfuck but non-ironically

In conclusion, this is what I think of you:

[X] You have some interesting ideas, but this won't fly.

[ ] This is a bad language, and you should feel bad for inventing it.

[ ] Programming in this language is an adequate punishment for inventing it.

<comment><USER5> In addition to being a space-hogging recapitulation of an old, boring Usenet joke, a lot of your checks are wrong; some of them are because the Usenet joke is lame, but some of them are just you missing things, like the fact that Swift interacts directly with C/ObjC, uses the same IDE as Cocoa developers already use, &c.

This lame Usenet joke was a way of punching down at people joining language newsgroups trying to get people to pay attention to their half-baked language ideas. This, on the other hand, is a language that was introduced on stage at WWDC by Chris Lattner. You can see how especially clumsy the joke is by the fact that you checked off a reason Swift "wasn't going to fly". Obviously, it's going to "fly" just fine on the Mac and in iOS.

<comment><USER202> I posted the checklist partly in jest, but also because I think it illustrates how every programming language ends up stuck with the same trade-offs.

<comment><USER203> Well, I thought it was funny and I enjoyed reading through the list. You're absolutely right that it provides an insight into the past language efforts and the trade-offs that they inevitably encounter.

I hope you remember that when someone tells you something like 'it doesn't work here' that it's an opinion rather than a fact, regardless of how they phrase it.

The USENET era, while sometimes dated, was probably one of times in 'geek' history where we were the closest to one another. The internet was interpersonal, and i'm glad that someone is still trying to propagate the humor and spirit from that time.

<comment><USER202> I'm not actually familiar with the context in which this checklist was originally written. But I really love it for two reasons:

First, it demonstrates how programming languages have been making the same tradeoffs for years, to the point that someone was able to make a checklist of what's wrong with any programming language that still works years later.

Second, you can fill this out for any of the big programming languages and many will do very badly. It shows how whether a programming language succeeds is unrelated to how good it is. An actually accurate checklist would have one item:

You're programming language will succeed because:

[X] It is tied to a popular platform.

</comment></comment></comment></comment></comment><comment><USER204> Oh sweet!

Another shrub in the walled garden!

</comment><comment><USER205> Logo looks a lot like a hammer and sickle.

</comment><comment><USER206> Great!!!!! i never liked Objective-C anyways

</comment><comment><USER207> This is massive.

</comment><comment><USER208> Hijacking another programming language name for your own cheap JS-syntax clone? Nice move, jerks!

<comment><USER171> Is that it? You have nothing more to say? JS, really? Can I say Scala?

</comment></comment><comment><USER209> [https://developer.apple.com/swift/](https://developer.apple.com/swift/)

</comment><comment><USER210> "...we wondered what we could do without the baggage of C."

Is that tongue in cheek? It's not even a particularly large, encumbered language, C.

<comment><USER211> Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know totalitarian governments have already exploited this to monitor citizens and torture or kill them.

If that isn't enough, how about goto fail? All the IIS exploits in v4/5? Various Windows RPC overflows, WMF overflows, SQL Slammer, et al? How many billions in damages have been caused by stack smashing and buffer overflows? How many millions of hours of manpower wasted cleaning up after these errors? Toyota killed some people because their dumb code overwrote memory, blasting the OS task tables causing the watchdog task to stop getting CPU time, meaning nothing provided a stopgap against unintended acceleration. People are __literally __dying because we can 't fucking let go of C.

C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! How can I power-slide? I want full control; I need to pump the breaks. People should just drive better, then we'd have fewer accidents".

We've been trying to "drive better" for decades (Valgrind, lint, code reviews, static analysis tools, education, ASLR, NX protection, et al). We still regularly see massive security-smashing epic failures.

It hasn't worked. Furthermore the C standard library has been proven turing- complete for ROP gadgets in the presence of a buffer overflow. So no matter what you do, the presence of a single stack smash is enough to allow code execution, subject to payload size limits and execution time.

At some point we have to admit C is no longer acceptable. Not for libraries, not for drivers, not for operating systems. It has to go.

All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes.

Software allows us as programmers to greatly magnify our impact on the world; we like to think of that in positive ways. But the inverse is also true: thanks to the continued use of non-memory-safe languages we have the power to negatively affect the world on a massive scale.

It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period.

<comment><USER212> _It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period._

I'm looking forward to seeing your new operating system and managed runtime written entirely using garbage-collected languages!

<comment><USER213> I don't necessarily agree with the post you're replying to, but Rust is a memory-safe language without any garbage collection whatsoever. Proper unique pointers and move semantics are basically magic.

<comment><USER214> I'd be interested to know more about what you think of xenadu02's post. Practically, we can't completely stop coding in C/C++ yet, but a large class of software can be written in safer languages already, and it seems to me that once Rust is mature, we should strongly prefer it over C or C++. The security problems with non-memory-safe languages are really that bad.

<comment><USER213> We have to be realistic. C is never going away. C++ is never going away. When has any entrenched programming language ever gone away? As someone who has been paid to write code in RPG ([https://en.wikipedia.org/wiki/IBM_RPG#Example_code](https://en.wikipedia.org/wiki/IBM_RPG#Example_code)), I can confirm: never ever, ever ever. The best that we can do is to offer an alternative.

The _reason_ why I put so much effort into Rust is because people who need to write the software in this space have literally no alternative that is not unsafe. Even if they cared about safety, they're screwed! Say that they need to write a library that can be written once and called from any language. That means, effectively, that they need to write that library in a language that 1) can expose a C-compatible interface, and 2) can run without a runtime. Which means, practically, that their choices of programming language are either 1) C or 2) C++. Despite Heartbleed, nobody's rushing to rewrite OpenSSL in ML. And I sure hope nobody's rushing to rewrite it in Rust either (we have no idea yet how Rust would fare for crypto, and we need time to figure that out). But once Rust is ready, you will at least have a _choice_. Memory safety will no longer be something that you leave on the table out of necessity.

I feel like the vast majority of the new programming languages coming out these days were conceived to make programming more pleasurable for the programmer. And yeah, I'm a programmer too, and I dislike many of the languages that I am forced to use every day. But Rust isn't about making programmers happy (although it seems to do that entirely by accident); it's about making users safer. Fewer vulnerabilities, fewer angles of attack for the baddies to exploit. And hey, if it makes software crash less, I guess that's cool too.

<comment><USER215> > We have to be realistic. C is never going away. C++ is never going away.

Not in the coming years, but it eventually will become a legacy language like RPG is, confined to old boxes running on long term maintenance contracts.

All is needed are a few mainstream OS where those languages are no longer part of the standard SDK. Like for example Microsoft just did with C as of Windows 8. Even their latest C99 compatibility changes were only done as they are required by C++11/14, nothing else.

> I feel like the vast majority of the new programming languages coming out > these days were conceived to make programming more pleasurable for the > programmer.

This was already possible with Lisp, Smaltalk, Mesa/Cedar, Modula-2, back when C was created, but then AT&T had better relationship with universities than Xerox PARC and ETHZ did.

</comment></comment></comment></comment></comment></comment></comment><comment><USER216> Nothing about concurrency. Nice. STOP MAKING NEW LANGUAGES!!! This is like environment pollution and should be shunned.

</comment><comment><USER217> "You also don't need to write semicolons at the end of every statement."

Please. Please. PLEASE don't be whitespace delimited!

<comment><USER17> _Please. Please. PLEASE don 't be whitespace delimited!_

One of the prime examples I give for how HN/reddit has gone downhill was being downvoted by some clueless hipsters for suggesting that it would be easy to cross-compile from a whitespace-delimited language to a non-whitespace- delimited one. It's not some kind of huge fundamental divide in languages. For any non-whitespace delimited context free language, it should be possible to write a homomorphic transformation to a whitespace delimited one.

This is something that people should consider trivial and be beyond discussing.

<comment><USER217> If the solution for a feature intended to save time and reduce hassle ends up being "write and maintain your own compiler extension" it's a bad feature. Period.

I'm not a fan of whitespace delimiting or type inferencing because while they seems like they save you time and effort, I've found that in the long run you end up spending more time debugging your indentations here or type declarations there than you would have spent just explicitly declaring them in the first place.

<comment><USER114> I'm not sure how much Python you've written but I personally have never had to debug problems with whitespace. (I'm had to debug plenty of problems in other languages where the whitespace implied one thing but the curly braces said another).

</comment></comment></comment></comment><comment><USER218> Me (running arch linux): Oooh! I'd love to learn a new language. And great, they have a free ebook it looks like to describe it!

Apple: To download Apple Inc.'s 'The Swift Programming Language', you need to have iTunes.

Me: What?

Apple: Using a 64-bit edition of Windows? On a Mac?

Me: No.

That experience just killed a potential programmer for you right there, Apple.

I had a few hours to kill, and was pumped to jump on the next apple cash cow and help us both, but you literally killed my ability to download the manual or learn anything more about it for a few days, by which time I'll probably be onto something else.

They have this: [https://developer.apple.com/library/prerelease/ios/reference...](https://developer.apple.com/library/prerelease/ios/referencelibrary/GettingStarted/LandingPage/index.html) But it doesn't look nearly as in depth as the ebook would be.

<comment><USER219> If you're an Arch user, why would you learn a language that won't ever compile on anything other than OSX?

<comment><USER218> Because money.

</comment></comment></comment><comment><USER220> Our mentors & curriculum developers went bananas when they heard about Swift – so we announced the first course teaching Swift: [https://www.thinkful.com/a/dlp/learn- blue/base/IOS-002](https://www.thinkful.com/a/dlp/learn-blue/base/IOS-002)</comment>


Aereo launching streaming broadcast TV service in NYC on March 14th - <AUTHOR> http://www.theverge.com/2012/2/14/2797616/aereo-streaming-broadcast-tv-pilot-launch-nyc

<comment><USER2> The fact that they built out thousands of little antennas (one per subscriber) to circumvent distribution laws is awesome.

</comment><comment><USER3> Entire generations are going to prettify the sub-$300 goal. Ala carte TV shows and not going to see the best to see here. This should define a non-client, self-sponsored study showed that it's been wired, by hand.</comment>


Apple releases iOS 6.0.1 with improvements and bug fixes - k-mcgrady http://9to5mac.com/2012/11/01/apple-releases-ios-6-0-1-with-improvements-and-bug-fixes/ <comment><AUTHOR> Interesting, over-the-air updating really is broken on the iPhone 5. When you check for updates, it has you download an "iOS Update Enabler" app.

<comment><USER2> And it has a shockingly beautiful animation of the settings icon. Truly just surprised me.

<comment><USER3> It's worth noting that the rotational speed of the wheels are different.

<comment><USER4> I'm willing to bet someone did their homework and those speeds are accurate. If you haven't seen it, check out the old school tape deck rotational speeds in the podcast app.

</comment></comment></comment></comment><comment><USER5> Also, iOS 6.1 beta for developers: [http://www.macrumors.com/2012/11/01/apple- seeds-first-ios-6-...](http://www.macrumors.com/2012/11/01/apple-seeds-first- ios-6-1-beta-to-developers/)

<comment><USER6> It's funny... Only (and only) MapKit has new APIs!

[https://developer.apple.com/library/prerelease/ios/#releasen...](https://developer.apple.com/library/prerelease/ios/#releasenotes/Miscellaneous/iOS61APIDiffs/index.html) (<\- you must be a developer to open this link)

</comment></comment><comment><USER7> Meh. What they really need to fix is Maps. In my family-and-friends ecosystem at least, that is the single reason NO devices have been updated to iOS 6 and nobody is buying any iPhone 5's. My rough guess that that represents about at least 30, if not 50 devices.

Is there a website somewhere that is tracking Apple Maps quality vs. Google Maps?

I know tons of people that have put updates and new-device purchases on hold due to Maps. I have a friend who owns a delivery company. All the drivers have iPhones. No updates, hardware or software. Apple Maps would turn his business upside-down.

<comment><USER8> The unfortunate thing is people need to use maps in order for maps to get better. I can already see few locations being corrected. But for now, looks like Apple's got a chicken and egg problem.

<comment><USER9> Could you please elaborate on that? Not sure I follow.

If people use it, get wrong directions, how does it improve? Are users able to make corrections or?

<comment><USER10> Yes, users can submit corrections using the 'Report a Problem' option in Maps. Apple will also be able to correct certain types of data, such as roads, by collecting and aggregating info from iPhones.

</comment></comment></comment></comment><comment><USER11> I'd say iOS6 has one of the more buggy first releases that I can remember, so I'm hoping there's a fair bit of work been done.

<comment><USER12> Tend to agree with this. There's some great stuff they've added for developers, but even non-technical users like my parents have complained about some bugs — not to mention how awful an experience Game Center is.

</comment></comment><comment><USER13> General Fixes:

• Fixes a bug that prevents iPhone 5 from installing software updates wirelessly over the air

• Fixes a bug where horizontal lines may be displayed across the keyboard

• Fixes an issue that could cause camera flash to not go off • Improves reliability of iPhone 5 and iPod touch (5th generation) when connected to encrypted WPA2 Wi-Fi networks

• Resolves an issue that prevents iPhone from using the cellular network in some instances

• Consolidated the Use Cellular Data switch for iTunes Match

• Fixes a Passcode Lock bug which sometimes allowed access to Passbook pass details from lock screen

• Fixes a bug affecting Exchange meetings

Security Issues Fixed:

• Maliciously crafted or compromised iOS applications may be able to determine addresses in the kernel

• A person with physical access to the device may be able to access Passbook passes without entering a passcode

• Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution

</comment><comment><USER14> Maybe this will help fix the battery issues. My iphone 5 battery life is horrid, even with LTE disabled and all mail data being set to fetch instead of pull. Is there some known issue about this? I can't be the only one.

<comment><USER15> I'm having a similar problem - but only when LTE is enabled... and I have spotty LTE coverage. When I'm in "the city" - LTE coverage is great and I get amazing battery life. As soon as my phone starts switching between 4G and LTE... my battery drains super-fast.

<comment><USER16> Your issue is a known issue with LTE. In spotty areas the phone keeps switching from LTE to 4G, and then when in 4G searches for LTE. The searching process, which requires powering separate radios for each protocol, is expensive power-wise. If you keep bouncing in and out of LTE this is bound to happen.

<comment><USER15> Is there any long-term fix for this? Or do I just have to wait for improved LTE coverage (or keep LTE turned off in those areas)?

<comment><USER16> It doesn't seem like a software issue to me, so I'd guess no fix will come aside from LTE coverage improving in your area.

It's just the cold hard facts of where the state of cellular radio technology is today. It's pretty amazing as is that the iPhone 5 can be so much thinner, lighter, support a larger hi-res screen, be twice as fast, and support LTE. The spotty LTE issue is just one of those compromises that I don't think much can be done about.

</comment></comment></comment></comment></comment><comment><USER17> Maybe replace link with <http://support.apple.com/kb/DL1606>

<comment><USER18> The real list must be longer than this.

<comment><USER19> It's better than the average patch notes out of Apple, which often essentially read "fixes stuff".

</comment></comment></comment><comment><USER20> I'm guessing that the maps app can be improved simply by updating their end of things and not exactly the actual application on the phone. Is this correct? I remember hearing that the dev team is updating and fixing issues, so is it just a covert type of thing that's going on in the background?

<comment><USER21> The complaints are almost universally about the quality of the data, which can definitely be fixed on the backend without requiring an update.

</comment></comment><comment> k-mcgrady I was hoping this would fix the wifi problem I'm having (wifi is incredibly slow and the problem is not related to my network) but it doesn't seem to have fixed it. Probably going to have to get the phone swapped out now.

</comment><comment><USER22> Is it known if this fixes the 'dead wifi' bug?

[http://www.wired.com/gadgetlab/2012/09/wi-fi-issues- plague-i...](http://www.wired.com/gadgetlab/2012/09/wi-fi-issues-plague- ios-6-upgrade/)

<comment><USER23> That was fixed pretty quickly: [http://erratasec.blogspot.be/2010/09/apples- secret-wispr-req...](http://erratasec.blogspot.be/2010/09/apples-secret-wispr- request.html)

<comment><USER22> That's not it. This is an entirely different bug, the wifi 'enable' slider is grayed out and stays grayed out. Several iPhones in my vicinity (all 4s) have the exact same problem and so far I haven't found a way to fix it.

<comment><USER23> Ouch, that can't be fun :/ I haven't heard any solutions to that one in particular, but I can't say I've looked. Hopefully, though.

</comment></comment></comment></comment><comment><USER24> Wait a little while with this update if you use the Facebook app. Since I installed 6.0.1, the Facebook app crashes immediately after starting.

EDIT: Hmm, after 10 crashes it started to work.

<comment><USER25> Well, the update here just broke 3G and no cellular data is working. Iphone 4. Dunno if it's my network provider's fault or the update's.

<comment><USER26> Check your mobile data settings. They get wiped after every update for me.

</comment></comment></comment><comment><USER27> Also, Xcode 4.5.2 has been released to go along with it:

<https://developer.apple.com/downloads/>

</comment><comment><USER28> Does anyone else have an issue with "Message Send Failure" for almost every _text_ message (not iMessage)? Wondering if this fixed that.

<comment><USER19> There've been at least two iMessage outages in the last week or so (widespread enough that iMessage trended on Twitter both times).

<comment><USER9> > _text message (not_ _iMessage_ _)_

I think he's talking about cell service.

</comment></comment></comment><comment><USER29> Listening to a podcast. Unplug my headphones, podcast stops. Yay. Receive a call. Hang up call. Podcast starts playing again. Annoying.</comment>