Swift, definition of version 1.0 and ABI stability

[zhiel]

I don't have any opinions on Swift itself, just their versioning. Why would you release 1.0 without a stable ABI? We just had a choice of Swift or Obj-C in our project and Obj-C won by a landslide because its stable. Swift just seems like a toy language that Apple screwed up a long time ago by releasing it way too early. It is basically useless if you need to do anything else than source based integration. I am baffled and confused.

[melling]

Wrong choice.

https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti...

You are placing too much emphasis on compatibility. You'll do less work writing in Swift and fixing any changes than writing all that Objective C code.

[rdsnsca]

Parts of El Capitan are written in Swift. See :

http://daringfireball.net/thetalkshow/139/federighi-gruber-t... From the Link :

"FEDERIGHI: We have all types here within Apple. They start out with the “I love Objective-C. I don’t want to change” to “OK, maybe there’s something to this Swift thing” to “Let me give it a try” to “I love it.” We’ve gone through all the phases internally. You know, we’ve had some really great adoption by teams like … the team that does the Dock and the window management on OS X, implemented all their new features for El Capitan in Swift and started mass-converting all of their code, and say that they couldn’t imagine going back and that they’re more productive with it. Part of what our internal teams need to deal with, though, is that they’re working on, let’s say, the current version of Swift 2.0 while it’s not done yet. I mean, while it’s not even WWDC-level done yet, right? And they’re working on the interfaces in terms of our internal frameworks that haven’t been modernized for Swift. And so, they’ve got it rough. They’ve got to really love it to make that leap because they’re working on a very, very bleeding-edge environment when we use it internally. Thankfully, with Swift 2.0 now well out the door, that’s stabilized things a good bit and they’re really open to it.

But there’s been just lot of feedback. And a lot of it has helped with the impedance, making sure the impedance between Objective-C and Swift is absolutely minimized because of course we have and will continue to have and continue to write more Objective-C code, and so the ability of Swift and Objective-C code to work together completely naturally is a huge focus. A bunch of things like generic collection, support for lightweight generics in Objective-C, were big pain points internally and something we fixed in the language, and is now great for all of our app developers externally. So, it’s been a not dissimilar road for us internally to what you see outside. But in terms of Swift and writing big apps, it’s certainly the case that when Swift 1.0 came out — heck, we didn’t support incremental compilation in the very first update. And so that was going to be a limiting factor for productivity for people who had big apps. A lot of that stuff has changed. And then in 2.0 having a good error-handling model, having the availability check so you could span API versions — these sorts of things. I think it really addressed the vast majority of pain points that we were experiencing, that I think the community was experiencing about writing larger apps. And so much about Swift is actually inherently better for building big apps because it handles modules and namespaces in a way more naturally than in Objective-C. It makes the API contracts a little more clear, the code more obtainable. So, we’re very comfortable."