▲ 434 points
back
367 comments
This will take a while, but I'm looking forward to it.
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.
Yes, and it means Swift scripts and modules that don’t reference UIKit/AppKit/SwiftUI/Combine will run on Linux and possibly Windows with zero or little modification.
I‘m a little sad though that they didn’t start this endeavor years ago, because IMO Rust has already built so much momentum that it will win (for the popular, medium to long term definition of „winning“).
Swift is great. I’ve done a lot of it, but also bounced around between Typescript, Elixir and Java and every time I miss Swift’s strongly opinionated, highly descriptive and flexible style.
Also, for the most part, it’s vastly superior to Obj C. The sad thing is that when writing Obj C I often find myself not writing the clean, well structured solution that’s in my head out of sheer resistance to the verbosity that it would take. I always just keep thinking how simple it would be in Swift and how much longer and more keystrokes / files it takes in Objective C.
Waiting for things to settle down on the server side and will gladly use Swift for web APIs once dust settles as the lang is really nice for the most part.
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...
Thanks for that, always appreciaet Tsai's perspective and this part stuck out to me:
>it sounds like the plan is to rewrite it in Swift and extend Swift to allow Objective-C to call the Swift implementation of the old API
Not sure why but most people don't seem to have noticed that people outside Apple will now be able to contribute to Foundation and these contributions will ship across all platforms.
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.
I would recommend people always use language like Rust or C++ instead of swift, so that it is easy to make cross-platform apps. The UI can be made using a native toolkit like swift, gtk, winapi, etc... however, the core engine app should be written in a language like Rust.
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.
Foundation was developed for the needs of EOF so it makes sense there was a version for the Java WebObjects. There's almost certainly NeXT-derived code in macOS/iOS with a longer pedigree and a bunch of it will probably outlast the Foundation rewrite. As software evolution goes, it's an astonishingly long run, no doubt. Especially for a technology that very nearly went extinct.
WebObjects is actually still alive and kicking, but only inside of Apple
A lot of the web services that Apple provides still use that implementation of Foundation :)
From the day I realised that, I’ve never ceased to be amazed by how many things have come from Next or were derived from it. I find it quite astounding.
I thought it was NeXTSTEP/Sun, but it seems disputed. https://stackoverflow.com/questions/473758/what-does-the-ns-...
What happened to WebObjects? And why did Apple left the business market?
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?
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.
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:
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:
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
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.
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.
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.
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?
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.
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.
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!
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.
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.
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.
9 years after the created this language they’re only now beginning to do this?
How prospective it is to jump on the iOS bandwagon in 2023?
This is an other step in the direction to a Swift-only Apple platforms.
I don't think it would be worth my time to even buy a other macOS device to port my framework.
I don't think they will get any benefit from 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).
These sorts of statements in the industry always make me ask, "So did you guys make something terribly slow first, and then bring performance back close to where it originally was?"
I'm not sure if the current Calendar app was ported to Swift, was originally Objective-C based, and such efforts to move Foundation to Swift will just... make Calendar fast again?
Also, Calendar doesn't seem to be particularly slow in the first place. But I love performance engineering, and quality of life is big, so... hey cool.
“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).”
I’m sure it is, but this is not solving the right problem at all. Calendar is all UI. It needs to be lovingly gone over, not this.