Inside Swift
eswick.com
eswick.com
At least no one has started writing any horrible books on Swift yet.
In this case, I am actually featured prominently in this article--it isn't just that I know a lot about iOS or about Swift, but as the second half of this article and arguably the whole reason it was written was to show how to use Substrate (something I wrote) with Swift, I think it would be difficult to claim anything I say on the matter is "me too"--but even if it were someone totally random, I don't see why it should ever be considered a bad thing to direct people to more information :(.
(FWIW, I actually don't consider this article entirely correct: the information here implies that the symbols are available for all functions, and that was not my experience while on stage disassembling the WWDC app. I think I may need to parse the embedded Swift modules and provide new APIs for developers to look up methods out of the vtable, but before I go too crazy with that I am interested to see where the Swift-provided Swift.reflect ends up going.)
Or should any other who has written related material not inform HN, because someone other's articles were posted first?
Correct me if I'm wrong (and my point certainly isn't meant to detract from the interest of looking more in-depth at Swift internals), but this article doesn't appear to support this claim at all. It seems equivalent to saying Scala isn't meant to replace Java, or C assembly, because at the end of compilation it's all just Java. Abstraction is real. Also, Apple is providing a "migration guide" for porting Objective-C apps over to Swift. Nothing is conclusive, obviously, but certainly the article does not show that Apple doesn't intend for Swift to ultimately replace Objective-C as the primary language of Mac development.
Perhaps that line in article meant that it's not binary identical to Objective-C. Swift classes definitely use different method invocation semantics (unless you adorn the class with the @objc attribute).
The Objective-C runtime takes the role of COM in Mac OS X/iOS.
A binary ABI between OO languages.
What's _really_ going to be interesting going forward is whether Apple introduces new features in the runtime that are only available to Swift code, or whether it starts making change to the runtime that favour Swift over Objective-C—and that's probably going to tell us when the latter is to be considered a legacy language.
/Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
Also try :gui command inside the REPL xcrun swiftHow well does compatibility fare?