Apple announces full Swift rewrite of the Foundation framework (2022)(infoq.com)
infoq.com
Apple announces full Swift rewrite of the Foundation framework (2022)
https://www.infoq.com/news/2022/12/apple-swift-foundation-rewrite/
367 comments
Similar post by Michael Tsai with some quick summary points of the impact of this:
https://mjtsai.com/blog/2022/12/12/the-swifty-future-of-foun...
https://mjtsai.com/blog/2022/12/12/the-swifty-future-of-foun...
Good for Apple. In my opinion they are laying the groundwork for reducing technical debt.
Objective-C had a good run. I haven’t used Objective-C in over 10 years but I have used Swift about 10% of the time in the last four years. Swift is a nicely designed language and I could see it supporting Apple’s business for many years.
Will Swift ever be a primary language on Linux? I would say yes, except now that Rust is used the advantages of also mixing in Swift are diminished.
Objective-C had a good run. I haven’t used Objective-C in over 10 years but I have used Swift about 10% of the time in the last four years. Swift is a nicely designed language and I could see it supporting Apple’s business for many years.
Will Swift ever be a primary language on Linux? I would say yes, except now that Rust is used the advantages of also mixing in Swift are diminished.
Who else remembers when they re-implemented the (at the time version of) the Foundation framework in Java for WebObjects? That was, what, 1998? Right around when NeXT got re-absorbed by Apple, not sure if the rewrite was started before or after.
https://developer.apple.com/library/archive/documentation/Le...
https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-...
Those were the days! Actually kind of amazing that the Foundation framework is the result of steady evolution of an ObjC framework written by NeXT... over 30 years ago? All those `NS` prefixes that are still hanging on are for `NextStep`.
If this really replaces the ObjC implementation... would that be the final sunset of the codebase that has been there (at least ship of theseus style) from NeXTStep days? I wonder if there's continuous version control history of Foundation source from the start, and how many, if any, lines of code remain from the initial implementation.
https://developer.apple.com/library/archive/documentation/Le...
https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-...
Those were the days! Actually kind of amazing that the Foundation framework is the result of steady evolution of an ObjC framework written by NeXT... over 30 years ago? All those `NS` prefixes that are still hanging on are for `NextStep`.
If this really replaces the ObjC implementation... would that be the final sunset of the codebase that has been there (at least ship of theseus style) from NeXTStep days? I wonder if there's continuous version control history of Foundation source from the start, and how many, if any, lines of code remain from the initial implementation.
The article quotes this:
> With a native Swift implementation of Foundation, the framework no longer pays conversion costs between C and Swift, resulting in faster performance.
and this:
> A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation).
First, that range of 1.5x-18x is kind of huge. Why?
Second, why would the intro with C be such a big performance penalty even assuming it's just 1.5x? I know there must be an overhead, but why so large?
Also, why single out the Calendar? Is it somehow representative?
> With a native Swift implementation of Foundation, the framework no longer pays conversion costs between C and Swift, resulting in faster performance.
and this:
> A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation).
First, that range of 1.5x-18x is kind of huge. Why?
Second, why would the intro with C be such a big performance penalty even assuming it's just 1.5x? I know there must be an overhead, but why so large?
Also, why single out the Calendar? Is it somehow representative?
I don't know Swift too well but my impression is that the support on Linux within the Foundation is not complete. (Also, is Foundation the same thing as what one might normally term a standard library? I can't tell.)
Does this change imply better (eventual) support on non-Darwin systems? Or maybe I've misread it and the change is unrelated.
Does this change imply better (eventual) support on non-Darwin systems? Or maybe I've misread it and the change is unrelated.
The removal of C from Android and iOS is going to pay off massively. The current state of things where every government is sitting on an endless collection of exploits is not ideal.
Correction: rewrite of PARTS of Foundation
There already was an open-source project to rewrite ALL of foundation, but it had stalled on the shores of having to re-implement everything:
The announcement:
What's Foundation? Swift's most-core library is the stdlib, tightly coupled to the compiler/language version, providing things like arrays, dictionary, etc., and available wherever Swift is. Beyond that, Foundation is the library with core API's for common features, e.g., for dates and concurrency. Stdlib is fully cross-platform and Swift-specific, but Foundation is a beast with API's dating to NExT with support for 20 years of API's.
Microsoft famously arrived at porridge for an operating system by maintaining backwards compatibility. Apple has cracked open Swift by developing in the open, but it's still Apple-funded and Apple-driven. Library and some integration support for other platforms has always had to come from community (notably compnerd's heroic effort to make-things-work on windows, and a revolving cast wanting Linux support for their server API's).
But there's no good reason to impose the whole Foundation history on other platforms. And there may be a movement inside Apple to migrate internal code to newer async API's, designed after the recent Apple-silicon generation.
For developers with server experience and some free time in a tech lull, it could be a good opportunity to help rebuild a new, er, foundation for computing on all devices, that's native but type- and memory-safe. The community is large and mature, but there is plenty of room for others.
There already was an open-source project to rewrite ALL of foundation, but it had stalled on the shores of having to re-implement everything:
https://github.com/apple/swift-corelibs-foundation
The announcement:
https://www.swift.org/blog/future-of-foundation/
https://forums.swift.org/t/what-s-next-for-foundation/61939/103
What's Foundation? Swift's most-core library is the stdlib, tightly coupled to the compiler/language version, providing things like arrays, dictionary, etc., and available wherever Swift is. Beyond that, Foundation is the library with core API's for common features, e.g., for dates and concurrency. Stdlib is fully cross-platform and Swift-specific, but Foundation is a beast with API's dating to NExT with support for 20 years of API's.
Microsoft famously arrived at porridge for an operating system by maintaining backwards compatibility. Apple has cracked open Swift by developing in the open, but it's still Apple-funded and Apple-driven. Library and some integration support for other platforms has always had to come from community (notably compnerd's heroic effort to make-things-work on windows, and a revolving cast wanting Linux support for their server API's).
But there's no good reason to impose the whole Foundation history on other platforms. And there may be a movement inside Apple to migrate internal code to newer async API's, designed after the recent Apple-silicon generation.
For developers with server experience and some free time in a tech lull, it could be a good opportunity to help rebuild a new, er, foundation for computing on all devices, that's native but type- and memory-safe. The community is large and mature, but there is plenty of room for others.
Does it mean Objective C is going to be second-class language? It would be a pity, I prefer Objective C to Swift.
Very short discussion last month:
https://news.ycombinator.com/item?id=33923484
https://news.ycombinator.com/item?id=33923484
Someone knowing existing pattern help me understand this. right now when i use these “foundation” apis in swift it is doing c call? so they rewriting now the c code in swift? (dont do ios or mac code so now sure)
me dont understand what make it faster now. i once wrote some jni code to call c++ library from java. does mean there some similar code to do cross language call? they get rid of it and so things now faster?
offtopic but debugging crashes in c++ over jni call was super hard. logs not work and me not figure out how to fix. wonder if they had similar “troubles” and this make everything easier :)
always feel skeptical when seeing large code base have “rewrite”. try many time in me career thinking there good reasons but super hard and not best value in end
me dont understand what make it faster now. i once wrote some jni code to call c++ library from java. does mean there some similar code to do cross language call? they get rid of it and so things now faster?
offtopic but debugging crashes in c++ over jni call was super hard. logs not work and me not figure out how to fix. wonder if they had similar “troubles” and this make everything easier :)
always feel skeptical when seeing large code base have “rewrite”. try many time in me career thinking there good reasons but super hard and not best value in end
Every time like this, bunch of people who believe safe programming is a language capability will jump out.
But in fact, the most valuable part of the code in any nontrivial system is the “unsafe” yet safe ones. You write memory safe code by understanding how computers memory works, sometimes you can use certain patterns to make that process easier, but not always. This is regardless what language you use: you programming in Rust, still the most valuable part is where one can get the “unsafe” part right.
A good C programmer will always a better Rust programmer when he wants to. That’s it.
But in fact, the most valuable part of the code in any nontrivial system is the “unsafe” yet safe ones. You write memory safe code by understanding how computers memory works, sometimes you can use certain patterns to make that process easier, but not always. This is regardless what language you use: you programming in Rust, still the most valuable part is where one can get the “unsafe” part right.
A good C programmer will always a better Rust programmer when he wants to. That’s it.
It looks like an important step in progressively retiring ObjC. Swift is built from the start with a ObC compatibility in mind, which is a source of much ugliness and inefficiency in the language. With the Swift team working in a value semantic first language (Val), I can kind of see where this is going.
Really looking forward to OOP being phased out.
Really looking forward to OOP being phased out.
[deleted]
Could someone please explain what exactly is the “Foundation”?
Is the Swift compiler itself written in Swift? How is it bootstrapped from source?
What remaining Apple frameworks are not yet written in Swift?
Wait, no more "po [$arg1 reason]"?
I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. And that's coming from a Rust fan. It will be interesting to see how effective this rewrite is.
Tangental question: How do you Swift-using, non-app developers find out how to do basic anything non-app related, such as reading files and making network connections?
I Google for stuff and probably 3/4s of the result are out of date and won't work in any reasonably modern version of Swift. I find Apple's Developer documentation sub-par, to say the least. So, how do you navigate it all?
It's quite a shock coming from stuff like Go, C#, and Rust.
It'd be pretty cool if there were a good version of the Swift Cookbook Ala the classic Perl Cookbook.
I Google for stuff and probably 3/4s of the result are out of date and won't work in any reasonably modern version of Swift. I find Apple's Developer documentation sub-par, to say the least. So, how do you navigate it all?
It's quite a shock coming from stuff like Go, C#, and Rust.
It'd be pretty cool if there were a good version of the Swift Cookbook Ala the classic Perl Cookbook.
Is there anything genuinely innovative about Swift or is it just another "cross-platform scripting language" that I'll only see on 1 platform?
The only reason I learned Powershell is because I have to admin for Windows. At least Powershell is interesting for its pipeline and object handling. I get not one spark of joy from Swift, and the comments I see are "at least we're not writing C anymore". Stockholm syndrome.
Sorry this is so negative, but I can't get excited about $NewLanguage unless I know it offers real benefit. I have drunk the Rust koolaid, and for very good reasons. What am I missing in Swift?
The only reason I learned Powershell is because I have to admin for Windows. At least Powershell is interesting for its pipeline and object handling. I get not one spark of joy from Swift, and the comments I see are "at least we're not writing C anymore". Stockholm syndrome.
Sorry this is so negative, but I can't get excited about $NewLanguage unless I know it offers real benefit. I have drunk the Rust koolaid, and for very good reasons. What am I missing in Swift?
Todd, you owe me $20.
(Todd said this would never happen)
Also, this is great news, and it will be interesting to see what kind of real-world changes in performance this has.
(Todd said this would never happen)
Also, this is great news, and it will be interesting to see what kind of real-world changes in performance this has.
So apple seems to be dropping c like languages, Microsoft says new stuff should not be written in c like languages anymore, and google has steadily worked towards using rust and go in place of c and c++ where it makes sense to do so it seems.
There seems to be a trend here.
There seems to be a trend here.
When the product of this hits the OS I predict massive instability. I don't think the Apple of 2022 has the level of systems programming talent that was behind the 1990s code in the core foundation. Today I feel like most of their attempts to move the OS forward beyond the shiny UI gimmicks (Tired of Exposé™? Try Stage Manager!™) are sloppy and only barely work (like "discoveryd" - google that if you don't remember).
If you don't believe me, quit all your non-Apple apps, and open up Console.app and hit Start streaming, and limit only to the "Errors and Faults" and watch the computer scream in logs until you're convinced. This is what modern Apple software quality looks like. I really don't want them touching anything near the core OS. Especially because when Apple software doesn't work, either you'll get no feedback, or it will say something comically vague like, that it "can't be completed."
I'd LOVE to be proven wrong here because otherwise I'll have to finally catch up on my Windows knowledge and get used to not having a GUI metakey separate from Ctrl!
If you don't believe me, quit all your non-Apple apps, and open up Console.app and hit Start streaming, and limit only to the "Errors and Faults" and watch the computer scream in logs until you're convinced. This is what modern Apple software quality looks like. I really don't want them touching anything near the core OS. Especially because when Apple software doesn't work, either you'll get no feedback, or it will say something comically vague like, that it "can't be completed."
I'd LOVE to be proven wrong here because otherwise I'll have to finally catch up on my Windows knowledge and get used to not having a GUI metakey separate from Ctrl!
It makes me so sad that swift, a compiled language more beautiful than Rust IMO, has such inferior support outside the Apple garden.
Apple has such an unpredictable stance on software development.
For example after all these years and lots of requests for such a feature it's still not possible to get notified about new reviews for your apps, but it's possible to get notified when a user edits a review after you've replied to it.
For example after all these years and lots of requests for such a feature it's still not possible to get notified about new reviews for your apps, but it's possible to get notified when a user edits a review after you've replied to it.
I was in a line once at WWDC in 2011. I happened to be in front of a group of Apple engineers. I overheard them discussing a rumored functional-ish language that Apple was to switch to from Obj-C. They didn't know what it was but they seemed skeptical that it would ever be put into real use. Glad to see it only took 11 years for it to permeate down to the Foundation framework. :)
This is pretty alarming.
I don't think Apple can do a full rewrite of Foundation, unless its opt-in only for Swift apps that have been ported to the new Swift-only codebase. If they are trying to opt in non-Swift apps, well, I'm glad I don't use OSX nor have to support it.
The article linked has few details on how they plan to do this, or how they plan on limiting the blast range.
I don't think Apple can do a full rewrite of Foundation, unless its opt-in only for Swift apps that have been ported to the new Swift-only codebase. If they are trying to opt in non-Swift apps, well, I'm glad I don't use OSX nor have to support it.
The article linked has few details on how they plan to do this, or how they plan on limiting the blast range.
Just switched back to windows after a decade with macos.
It seem that microsoft care way more about developers at the moment than Apple does. So much good stuff, open source, Linux subsystem, vscode, copilot, documentation, plugins, etc. Things works and are cheap and plentiful.
Beside the sleek and high quality hardware, nothing is missing.
It seem that microsoft care way more about developers at the moment than Apple does. So much good stuff, open source, Linux subsystem, vscode, copilot, documentation, plugins, etc. Things works and are cheap and plentiful.
Beside the sleek and high quality hardware, nothing is missing.
It's probably another big step towards "Swift everywhere," without worrying about bridging to C.
I've been doing little but Swift since 2014, and really like the language. I'm still "on the fence" about SwiftUI, but that's mostly because of the level of support from Apple, and the [im]maturity of the system. This will help with that.