Hacker News Reader

Comment by ruddct | Hacker News Reader

A lot of folks to thank at Apple right now, can't wait until all of this propagates so we can take a look at what's new in Swift 3. Two thoughts:

- VERY happy to see the open sourcing of much of the Foundation libraries (which includes strings, dates, networking primitives, concurrency/task queues, I/O, etc). It'll provide a very strong start and make working with Swift immediately productive.

- Holy crap, there's a package manager. This has been sorely needed since about day one of Swift development, glad to see that it's been a priority as part of the effort to open source!

View on HN

It doesn't look like they've opened any of the existing Foundation framework we all know and love and that's written in Objective-C. The swift-corelib-foundation repo contains a bunch of .swift files, and those contain lots of calls to NSUnimplemented().

The Core Foundation stuff (included in swift-corelib-foundation) has been open for a while: http://www.opensource.apple.com/source/CF/

The Foundation stuff is a complete Swift re-implementation of Foundation (fairly impressive goal) and is still in-progress (basic classes like NSArray and NSData look complete but none of NSURLConnection is implemented). They are targeting Swift 3 to have them complete. As the Core Libraries project page says:

"These libraries are part of the work towards the future Swift 3 release. They are not yet ready for production use, and in fact are still in the earliest stages of development"

NSURLConnection is deprecated in iOS 9 so I won't be surprised if they choose not to implement anything that's been deprecated.

> This has been sorely needed since about day one of Swift development, glad to see that it's been a priority as part of the effort to open source!

While not first-party, https://github.com/Carthage/Carthage

Swift's appears to possibly be limited to Swift, so Carthage will still be useful to integrate with Objective-C frameworks.

Well, Swift and C libraries via sysmodules actually.

so we can take a look at what's new in Swift 3

Are new versions backwards compatible?

Historically they haven't been, and the page about planning for Swift 3.0 says it will introduce breaking changes. (It also mentions that Swift 2.2 will be released in the interim and its compiler will try to warn about things that will be broken in 3.0 so you can get your code ready early.)

It's interesting to compare Swift 2 -> 3 to the Python 2 -> 3 upgrade experience. Apple will simply break whatever they need to break to get the improvements they decide would be valuable, move on, and anyone who doesn't follow is likely to be left in the dust.

Frankly, I welcome it after years of feeling like the only Python 3 user on Earth.

For the next few years, I expect Apple will wield a great deal more power over the Swift user community than the Benevolent Dictator For Life has wielded over his supposed minions. I hope we'll get a better language this way, and that these changes won't simply break third-party products to make changes that mostly benefit Apple.

Rich, powerful giant gives power to fork to the little people. Will it be like C#? Like Java? Eventually like Python? Should be interesting....

Swift 3 will be ABI stable, so things will break less - that might not include standard library stability, but Swift projects currently include a copy of the standard library to avoid that.

It's kinda maddening sometimes, I have an app that every time XCode is updated it pretty much has at least one little change that has to be done to get it to build again. It makes me somewhat dread every update.

But, at the same time, they keep users upgrading at the same relentless pace and so you generally don't need to worry about supporting 10 year old versions of the OS.

Cuts both ways I guess!

Swift does not have a large userbase for now, and users adopting it are anticipating the breaking changes from beginning. When it stabilizes and developers grow, breaking changes will be less likely.

These circumstances are no where near the same: Swift is a compiled language, and they carefully made the decision to embed all of Swift and its runtime libraries in your application, allowing them to break things without disrupting existing applications and without needing backwards compatibility cruft in their operating system. They also have essentially been actively discouraging people from writing libraries in Swift by pointing out constantly that there is not a stable ABI, so you only see a small handful of things written for it in comparison to Python.

Reply on news.ycombinator.com