15 ms·

Apple is rewriting Foundation in Swift

261 points by hnand 3y ago

FpUser 3y ago
[flagged]
xvilka 3y ago
It's sad Apple didn't jump on the Rust train, it would give them a major boost in security and maintaining ease.
- bsaul 3y ago
  Not sure if that's still the case, but Graydon Hoare was part of swift team. Swift also slowly introduces support of lifetime analysis with regards to concurrency, but the path they chose is pretty different : they started with an easy to use language, and moved toward advanced concurrency-related security features, trying to keep the language convenient. Rust went the other way. This makes a lot of sense considering swift's primary target: app developers that build end-user facing software, as opposed to core system developers for rust.
wlesieutre 3y ago
Previous discussion at https://news.ycombinator.com/item?id=34339153 https://news.ycombinator.com/item?id=34339153 (4 months ago, 371 comments)
cutler 3y ago
Considering Swift 1.0 was released in September 2014 I'm not exactly bowled over by how long it's taken Apple, with all their resources, to rewrite Foundation.
- goranmoomin 3y ago
  Well, Foundation was a mature Obj-C library at that point, Swift’s future was unclear, and Swift needed to have better Obj-C interop anyway. I think that Foundation being a Obj-C library effectively forced Apple into eating their own dog food (for the sorely needed Swift/Obj-C interop), so I don’t think rewriting Foundation in Swift would have been a good strategy for Apple.
- Sophistifunk 3y ago
  It's how they've always done things. It was about 10 years after the last 68k Mac shipped before the entire classic OS was power. Same with moving everything from carbon to cocoa.
  - KerrAvon 3y ago
    (Mac OS 8/9 was never fully PowerPC native.)
    - astrange 3y ago
      Because some 3rd party software either wasn't PPC, or hadn't actually tested their PPC support so it couldn't be used, or in some cases interpreting the 68k code was actually faster due to cache sizes.
- jmyeet 3y ago
  Rust began in the late 2000s and only in the last few years has started to reach a level of mainstream acceptance. Adoption for new programming languages takes significant time. Compiler development takes an awful lot of time. For Swift to be this mainstream after being introduced in 2014 is (IMHO) really quick. As for Foundation, core frameworks almost never get rewritten and for good reason. It's almost never worth it. Best case? You get functional equivalence. Worst case? You introduce bugs into something that millions or even billions of devices depend on. Those bugfixes may take many years. Every now and again we see bugfixes that are 10-20+ years old in things like GCC or the Linux kernel. Rewrites should never be undertaken lightly, particularly with less mature languages. Apple is (IMHO) being relatively aggressive with this.
- cwp 3y ago
  Actually, Apple delayed stabilizing the ABI (which would be required for rewriting low-level libraries) in order to work on other features that the community (ie, non-Apple users of Swift) needed more. If Apple had prioritized the needs of their own developers, this would have been done years ago. So kudos to Apple.
- raincole 3y ago
  I'd prefer this approach, rather than hastily rewriting a stable codebase in the coolest trendy language. 9 years is not that long for a programming language. PG's (in)famous eassy on Python Paradox [1] was written in 2004. By the time Python was 13 years old and it was still a "cool kid's language". [1]: http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
- geodel 3y ago
  Well one can find lot of examples in programing language world. e.g. Go's generic implementation, Java's value type implementation etc where things can take really long time to get implemented. It takes delicate confluence of factors like community interest, technical/financial resources and implementers agreement on desired approach to get a feature done. And all the money in world can't make it any faster.
- astrange 3y ago
  Swift has its own standard library, so there wasn't much reason to do this. In particular, it would've made things slower to mix them until the implementation was very mature. Also, this project's been going for a few years I think, since it's used for Swift on Linux.
  - lapcat 3y ago
    > Also, this project's been going for a few years I think, since it's used for Swift on Linux. That doesn't seem accurate: "The Foundation package is an independent project in its early incubation stages." "In the future, we will explore how to sunset the existing swift-corelibs-foundation and migrate to using the new version of Foundation created by this project."
    - astrange 3y ago
      swift-corelibs-foundation is what I meant, it contains a portable implementation of Foundation. Don't remember which parts were in Swift though.
politician 3y ago
[flagged]
- Sophistifunk 3y ago
  [flagged]
  - jwlake 3y ago
    I mean a realistic version of that comment is that you can use GTP* to make a set of unit tests. Then iteratively write a new version in swift to be bug compliant with the old version using GPT*. Then profit? The question really is why is swift <-> objc bridge so bad you need this software?
    - coldtea 3y ago
      >The question really is why is swift <-> objc bridge so bad you need this software? HUH? I don't even understand the question. A bridge is something redundant in itself. It doesn't have to be "so bad" to want to get rid of. Why keep going through a bridge when you could (after this effort) call the lib directly? And why maintain the same code in 2 different languages, an increasingly deprecated one, and your new one?
    - liuliu 3y ago
      > The question really is why is swift <-> objc bridge so bad you need this software? Do you want to keep using a UTF-16 backed String type while the world (including Swift) is on UTF-8? (Oh, and I am posing the question to Java too...)
  - keyle 3y ago
    That's a moo point anyway as Apple had put a ban on engineers using ChatGPT.
    - Smoosh 3y ago
      Clarus?
alberth 3y ago
For clarity, this is not https://www.foundationdb.org/ https://www.foundationdb.org/ Which Apple acquired years ago and then released it open source.
- benatkin 3y ago
  Ah, so Deno KV is using an open source database? I didn't realize that.
KingLancelot 3y ago
[dead]
SeanLuke 3y ago
[flagged]
- mym1990 3y ago
  What a weird usage of that word…
  - commoner 3y ago
    GP was probably looking for the word "astroturfing": astroturfing: > The disguising of an orchestrated campaign as a "grass-roots" event – i.e., a spontaneous upwelling of public opinion. https://en.wiktionary.org/wiki/astroturfing https://en.wiktionary.org/wiki/astroturfing agitprop: > Political propaganda disseminated through art, drama, literature, etc., especially communist propaganda; (specifically, communism, historical) such propaganda formerly disseminated by the Department for Agitation and Propaganda of the Central Committee of the Communist Party of the Soviet Union. https://en.wiktionary.org/wiki/agitprop https://en.wiktionary.org/wiki/agitprop
    - Grustaf 3y ago
      It's obviously not astroturfing since it's a statement from Apple themselves. Astroturfing, if we were talking politics, would be if Apple secretly funded swift user groups across the world to make it appear that people liked the language. Obviously they don't have to do that, since people love it.
    - SeanLuke 3y ago
      Oh, it is astroturfing to be sure. But I was just having fun with the propaganda inherent in the sentence too.
- draw_down 3y ago
  [dead]
- Grustaf 3y ago
  Which part of the statement are you disputing? It's clearly a very successful language, with a strong community.
zainhoda 3y ago
Long overdue -- there's a very noticeable difference in runtime errors with Swift libraries vs the rest. This is especially true of AVFoundation, which is an absolute mess of hidden and undocumented state. Swift optionals and enums will go a long way to fixing that.
- KerrAvon 3y ago
  This will not directly affect AVFoundation, or any other framework which is not Foundation itself.
  - stephen_g 3y ago
    Not as part of the work from this announcement, no, but it is surely an indication that Apple is moving in a direction where those other libraries will eventually be re-written in Swift too.
    - stephen_g 3y ago
      (Oops, I commented before looking at the link and thought it was pointing at something like this - https://www.swift.org/blog/future-of-foundation/ https://www.swift.org/blog/future-of-foundation/ - not the git repository! But you know what I mean)
- saagarjha 3y ago
  One of the interesting side effects of this is that those new libraries are going to have significantly worse introspection and hotpatching opportunities, so they better code them correctly, or things are going to really suck.
  - ponyous 3y ago
    Would you mind to elaborate why this is the case? I am not in Swift/Obj-c ecosystem so I'm just clueless.
    - 3y ago
progrus 3y ago
I freakin knew foundation was amazing. Argh.
- Xorakios 3y ago
  July 14 will tell. ;)
stephc_int13 3y ago
Well, this is one more step toward a fully Swift-only platform. Very soon it will not be possible to publish an app on iOS not built with the house language. For those who don’t know, using C/C++ and opengl was easily done on iOS for many years, as llvm/clang was the official compiler.
- plagiarist 3y ago
  You're going to be relieved when you find out Swift has been using LLVM this entire time.
  - stephc_int13 3y ago
    We’ll see. I have a bad feeling about this.
- DrBenCarson 3y ago
  Bad take. Swift heavily relies on LLVM. As long as you have LLVM IR, your support isn’t going anywhere. Not to mention Apple continues to be an outsized contributor to LLVM and clang (largely because they started and open sourced the projects)
  - kibwen 3y ago
    Apple funds LLVM, but it didn't start LLVM. "The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages. LLVM was released under the University of Illinois/NCSA Open Source License,[3] a permissive free software licence. In 2005, Apple Inc. hired Lattner and formed a team to work on the LLVM system for various uses within Apple's development systems." https://en.wikipedia.org/wiki/LLVM https://en.wikipedia.org/wiki/LLVM
    - GeekyBear 3y ago
      Apple hired Chris Lattner straight out of college. LLVM was the subject of his Masters Thesis. It existed, but certainly wasn't yet ready for prime time. You can watch Chris give a Tech Talk at Google introducing Clang and LLVM and going over the features added in LLVM 2.0 while he was at Apple. He joined Apple in 2005. and this talk was in 2007. https://www.youtube.com/watch?v=VeRaLPupGks https://www.youtube.com/watch?v=VeRaLPupGks
endisneigh 3y ago
For a second I thought this was referring to foundationdb. Was baffled
wudangmonk 3y ago
What a dumpster fire Swift turned out to be. My first experience with it saw compile times go up more than 10x from the previous objc code base. Everytime more and more of apple's libraries were replaced because all the objc stuff was considered obsolete the compile times got worst and worst. Its not like I dislike the language either but I think compile times matter so languages should not pretend like that doesn't exist. I can forgive Rust its giving you more than just type checking but Swift does not offer the same things yet it takes just as long or longer to compile.
- kitsunesoba 3y ago
  While low compile times are nice I don't find them strictly necessary for the day-to-day because I'm not constantly doing full builds. Swift's incremental compiles are more than fast enough for my needs, especially on M1/Ryzen 5000 or better.
- KerrAvon 3y ago
  They both compile slowly because they have similarly complicated type systems. What do you use in Rust that Swift doesn’t yet provide?
  - xedrac 3y ago
    Catch data races at compile time?
    - turdprincess 3y ago
      I don’t know much about Rust, but Swift can prevent data races at compile time by using the Actor type.
      - astrange 3y ago
        It could catch them before that using ownership, at the cost of lower performance. Though Swift concurrency is mostly about "concurrency" not "parallelism", which is the one that has data races.
orhmeh09 3y ago
This has been happening in public on GitHub since January, FWIW.
nixpulvis 3y ago
Still? How big is Foundation anyway? Or are we talking about the movie they released?
- throwaway894345 3y ago
  I think you’re thinking of the Foundation series (not movie) on Apple’s streaming service?
thrwawy74 3y ago
I just... completely don't understand the appeal of Swift beyond it being Apple's in-house language. I was excited for Foundation to become open-source. Using a language you'll really only find in 1 environment is a negative. I'm going to go feel ashamed for not getting excited about a language now. I should be celebrating "more languages", but Swift is just Apple. No one outside Apple chooses Shift unless they want to build something in Apple's ecosystem.
- carbocation 3y ago
  As someone who mostly writes Go, I enjoy Swift the language. I am guessing that your concerns are centered on Swift the ecosystem? (E.g., it's only used for Apple things, so there are probably not libraries for Thing X.) If so that makes total sense to me. If not, I'd be interested to hear more.
- 29athrowaway 3y ago
  There was a lot of excitement when it first came out. I tried Swift for Linux, and soon realized it was a meh experience (NS this, NS that... NextStep is still there) and switched back to Rust. It could have been a strong Rust alternative.
  - dwaite 3y ago
    That is partly what this article is about - a swift-native set of foundation modules.
    - 29athrowaway 3y ago
      Yeah but I am too invested in Rust right now
- vxNsr 3y ago
  While generally true that you’re not gonna find swift anywhere else, this company[0] is making their browser cross platform and using swift as the language. Apparently there’s a proof of concept runtime for windows that they’re actively working on. [0] https://arc.net/ https://arc.net/
w10-1 3y ago
The project to rewrite Foundation in Swift is many years old, and had been stalled. New in 2023 is instead NOT to match all of Foundation, but to make some core libraries that make Swift usable on many platforms. E.g., they broke out the very large internationalization/i18n tables required for unicode support into a separate module. It's very unlikely Apple would move off their own Foundation, which is well-understood and well-tested. This strategy permits them to incrementally sidle over, but continue with both for some time. Aside from servers, it's likely to look promising for multiple tiny devices - trusted computing, watches, headsets, airpods, etc.
- deleted 3y ago
  [deleted]
- plorkyeran 3y ago
  This is not the same thing as swift-corelibs-foundation, which is the old project that stalled out. The officially announced plan here is for it to fully replace the old implementation of Foundation.
  - BulgarianIdiot 3y ago
    Shame really. Apple's platform has so many good ideas I wanted Swift to bring to the world as a cross-platform open-source effort. :(
    - dwaite 3y ago
      Wouldn't that be this new Swift Foundations project?
- xenadu02 3y ago
  This is a new effort that is committed to shipping on Apple platforms. It will also be the first time 3rd parties can get code changes into Foundation.
  - saagarjha 3y ago
deleted 3y ago
[deleted]
LispSporks22 3y ago
Will it still all call send_msg and friends? Like can I still call into Foundation via C FFI or Objective C?
- plorkyeran 3y ago
  Yes. This is intended to be a reimplementation of Foundation with the same API, including being usable from obj-c. They've added a few compiler features recently to cover the gaps where there were some kinds of obj-c types that couldn't be defined from Swift.
ksec 3y ago
Not a popular opinion. Current Apple and Swift felt somewhat like Apple and Dylan in the 90s. May be time could tell. A lot of people hate Objective-C, and was cheering for Swift in 2014. Now nearly a decade later, it seems time and resources could have been spent somewhere else.
- pjmlp 3y ago
  Not really, Dylan failed to ship on NewtonOS, Swift not only is shipping across all Apple platforms, it is replacing Objective-C. Metal is the only green field framework that was still being built with Objective-C, and yet most just use the Swift bindings. Maybe Swift isn't Objective-C without C, as originally announced, but something else isn't coming to replace it either.
- Grustaf 3y ago
  What makes you say that? I don't think you can find many developers that would be willing to go back to Objective C.
  - mpweiher 3y ago
    Not sure why the only alternative to Swift is "going back", particularly when Swift is already going back in many ways. How about going forward to an alternative that actually isn't a step back.
    - pjmlp 3y ago
      That will only happen by moving to another platform.
    - Grustaf 3y ago
      Swift is an amazing improvement over objective c and I don’t think there are any languages out there that are obviously superior for the use case. The only people i ever hear complain are objc diehards and general apple haters.
      - 3y ago
synergy20 3y ago
not an apple fan,from obj-c to swift,why not just c++, NIH plus I-want-to-control-everything?
- Jtsummers 3y ago
  Objective-C was not invented at Apple. Hard to see how NIH applies there.
- Grustaf 3y ago
  If you look at C++ and then look at Swift I think you will understand why they didn't make C++ the main language.
- olliej 3y ago
  Because C++ is not memory safe, lifetime safe, type safe, has notoriously brittle ABIs, ...? Seriously if you're going to take the cost of rewriting massive amounts of code, why would you not rewrite it in a language that offers actual improvements to the language that's being rewritten? Apple already has (and uses) objective-c++, and the majority of objc I've ever interacted with is objc++ once you're outside of headers (just look for .mm extensions).
karismatic 3y ago
Swift has been a hugely successfully language. Mostly at slowing down iOS runtime performance per clock cycle, and increasing compilation times. Its also been hugely successful at punishing companies for using it, since it didnt really work for a few versions. While there have been fewer crashes (sort of) due to the switch, as someone who worked for years in Objective C and years in Swift, I honestly never felt that Swift significantly improved much except allocation rituals and properties. I do however enjoy Kotlin for the backend because it has some nicer semantics for object construction. While I do admire the work that Apple has put into Swift, I really felt that Apple was trying to "impress everyone", with a whole lot of bikeshedding and sick amoutns of code generation to convince us it was the right thing to do. Frankly, apps run over 10 times faster in obj C and xcode with Swift is probably my least favorite and sort of non-ergonomic experience close to DOS batch file dev in Windows Notepad.
- HacklesRaised 3y ago
  Given karismatic a prize. I wonder if the current state of affairs is what Chris L had in mind?
  - ihatepython 3y ago
    I don't know, but Chris L was always a C++ guy, he never really understood Objective-C in my opinion, which is why Swift ended up the way it did. I doubt he ever used it very much, or had a deep understanding of it.
    - rumori 3y ago
      I’m pretty sure Chris Lattner has a good grasp of Obj-C, after all they had to design Swift in a way it could easily interface with Obj-C. While Swift went through some versions to become stable, they were always transparent on the roadmap and had a very open attitude towards community proposals. Looking back I think it was a very well executed transition and would consider it a success in every way.
- Grustaf 3y ago
gyrovorbis 3y ago
Hot-take from someone who is currently helping to port GNUStep's implementation of the Foundation framework to the Sega Dreamcast: Gross. The whole appeal of Foundation was having this incredibly convenient, beautiful, high-level object-oriented API ontop of low-level, statically compiled performant C... The true path forward for computing is clearly an alliance among the holy trinity of god's C languages: C, C++, and Objective-C. Yes, the future is in Objective-C++'s hands.
- lloydatkinson 3y ago
  Somehow I doubt porting MacOS to old game consoles was Apple's priority when making this decision.
  - gyrovorbis 3y ago
    I'm not porting MacOS. I'm porting just the Foundation layer, and I'm not using Apple's implementation, I'm using GNUStep's. But hey, maybe having a core, foundational framework written in the most performant language out there with the most hardware support should've been a priority. ;)
- ridiculous_fish 3y ago
  Objective-C++ is underrated.
  - gyrovorbis 3y ago
    It really is a beautiful language, and some of the most powerful aspects of Swift are due to its Objective-C roots.
- xenadu02 3y ago
  Foundation has not been a pure layer on top of CoreFoundation for over a decade. Some class implementations are unified on the ObjC version, not the pure C CoreFoundation version. Objective-C got good enough that all processes on Apple platforms have the objc runtime in their address space whether they want it or not and many pure C or CF-like frameworks are built on ObjC under the covers.
can16358p 3y ago
The performance "optimizations" are all about eliminating the bridge between ObjC and Swift. I'd love to see a comparison of how the functions work within their own realm, e.g.: - Speed of a date function in pure ObjC, tested in ObjC realm with no Swift bridge - Speed of the same date function in pure Swift, tested in Swift realm with no ObjC bridge. Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline.
- lapcat 3y ago
  > Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline. This is a strange comment, because Swift would have been Dead On Arrival in 2014 without that Objective-C bridging, an Apple-created language that doesn't work with Apple application frameworks.
  - can16358p 3y ago
    Perhaps I articulated incorrectly. The bridge should have obviously existed (and should still exist for a very long foreseeable future if not forever). I was refering to having a benchmark with and without bridge and telling Swift is faster is a bit off, as that performance decrease was what Swift had to bring in the first place.
    - lapcat 3y ago
      Do you mean as some kind of Swift vs. Objective-C argument? I don't think Apple is interested in having that argument in 2023. There's no point. Swift has won the "language war", politically within Apple and in developer mindshare outside Apple. (I say this as someone who continues to write Objective-C.)
      - can16358p 3y ago
        Nope, Swift clearly won (which was created by Apple themselves to replace ObjC in most places if not all eventually). I think the metrics in their current form don't really mean much if it's only measuring the performance "gain" by getting rid of the ObjC/Swift bridge.
wildpeaks 3y ago
The Swift feature I miss in other languages is `enum` cases with parameters and `switch` blocks having to cover all cases, it's so convenient.
- bsaul 3y ago
  same here. I don't understand how this feature hasn't landed in every other compiled languages (i'm looking at you golang)
- dwaite 3y ago
  Both of these are also shared with Rust FWIW. I believe Swift takes the switch farther than match in Rust, because it tries to deal with API stability (e.g. a system library adding new possible cases)
- dontlaugh 3y ago
  Proper sum types are so useful, it's a tragedy so many statically typed languages lack them.
tagyro 3y ago
I might be in the minority here (though, reading the comments, it seems others have the same opinion), but I find Swift to be a step back compared to Objective-C. I really like the verbosity of Objective-C - this makes the code more readable and easier to understand, even (or especially) when reading a program the first time. Being a superset of C (and C++ with Objective-C++) means that, when necessary, one can easily write a C (or C++) method (or class) but also include existing C/C++ libraries. I also find some of the improvements Swift brings to actually make developers more reckless and dependent on the language/compiler (yes, I liked to manually manage memory). And a bit of a personal frustration: I find a swift package/project that I want to use, download it and ...start fixing/updating the code, so that it compiles with the latest Swift version. I still have Objective-C code I wrote more than 10 years ago that compiles and runs with minimal or no change.
- lapcat 3y ago
  > yes, I liked to manually manage memory I think you are in the minority there, even among Objective-C programmers. In any case, Objective-C ARC is there for those who want it.
- s_dev 3y ago
  >I might be in the minority here I think for sure you're in the minority here. Swift was really a breath of fresh air for my iOS dev work -- it's just so modern and easy to read. That said -- I'm still reluctant on SwiftUI though. Seems like one of those technologies that works great for small apps and tutorials but falls apart at scale but admittedly have little experience with it so perhaps I'd be wise to reserve judgement.
  - rumori 3y ago
    I’m with you on the SwiftUI skepticism. After 10+ years of native iOS development - can’t believe I’m saying this - but I thoroughly enjoy Flutter, it’s open source I can easily modify anything I want, the tooling is great, VS Code plugin is great, and hot reloading a live app is just amazing. It’s everything SwiftUI should be, let’s see what new stuff they announce at WWDC.
- 3y ago

261 points by hnand 3y ago

FpUser 3y ago

[flagged]

xvilka 3y ago

It's sad Apple didn't jump on the Rust train, it would give them a major boost in security and maintaining ease.

bsaul 3y ago
Not sure if that's still the case, but Graydon Hoare was part of swift team. Swift also slowly introduces support of lifetime analysis with regards to concurrency, but the path they chose is pretty different : they started with an easy to use language, and moved toward advanced concurrency-related security features, trying to keep the language convenient. Rust went the other way. This makes a lot of sense considering swift's primary target: app developers that build end-user facing software, as opposed to core system developers for rust.

wlesieutre 3y ago

Previous discussion at https://news.ycombinator.com/item?id=34339153 https://news.ycombinator.com/item?id=34339153 (4 months ago, 371 comments)

cutler 3y ago

Considering Swift 1.0 was released in September 2014 I'm not exactly bowled over by how long it's taken Apple, with all their resources, to rewrite Foundation.

goranmoomin 3y ago
Well, Foundation was a mature Obj-C library at that point, Swift’s future was unclear, and Swift needed to have better Obj-C interop anyway. I think that Foundation being a Obj-C library effectively forced Apple into eating their own dog food (for the sorely needed Swift/Obj-C interop), so I don’t think rewriting Foundation in Swift would have been a good strategy for Apple.
Sophistifunk 3y ago
It's how they've always done things. It was about 10 years after the last 68k Mac shipped before the entire classic OS was power. Same with moving everything from carbon to cocoa.
- KerrAvon 3y ago
  (Mac OS 8/9 was never fully PowerPC native.)
  - astrange 3y ago
    Because some 3rd party software either wasn't PPC, or hadn't actually tested their PPC support so it couldn't be used, or in some cases interpreting the 68k code was actually faster due to cache sizes.
jmyeet 3y ago
Rust began in the late 2000s and only in the last few years has started to reach a level of mainstream acceptance. Adoption for new programming languages takes significant time. Compiler development takes an awful lot of time. For Swift to be this mainstream after being introduced in 2014 is (IMHO) really quick. As for Foundation, core frameworks almost never get rewritten and for good reason. It's almost never worth it. Best case? You get functional equivalence. Worst case? You introduce bugs into something that millions or even billions of devices depend on. Those bugfixes may take many years. Every now and again we see bugfixes that are 10-20+ years old in things like GCC or the Linux kernel. Rewrites should never be undertaken lightly, particularly with less mature languages. Apple is (IMHO) being relatively aggressive with this.
cwp 3y ago
Actually, Apple delayed stabilizing the ABI (which would be required for rewriting low-level libraries) in order to work on other features that the community (ie, non-Apple users of Swift) needed more. If Apple had prioritized the needs of their own developers, this would have been done years ago. So kudos to Apple.
raincole 3y ago
I'd prefer this approach, rather than hastily rewriting a stable codebase in the coolest trendy language. 9 years is not that long for a programming language. PG's (in)famous eassy on Python Paradox [1] was written in 2004. By the time Python was 13 years old and it was still a "cool kid's language". [1]: http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html
geodel 3y ago
Well one can find lot of examples in programing language world. e.g. Go's generic implementation, Java's value type implementation etc where things can take really long time to get implemented. It takes delicate confluence of factors like community interest, technical/financial resources and implementers agreement on desired approach to get a feature done. And all the money in world can't make it any faster.
astrange 3y ago
Swift has its own standard library, so there wasn't much reason to do this. In particular, it would've made things slower to mix them until the implementation was very mature. Also, this project's been going for a few years I think, since it's used for Swift on Linux.
- lapcat 3y ago
  > Also, this project's been going for a few years I think, since it's used for Swift on Linux. That doesn't seem accurate: "The Foundation package is an independent project in its early incubation stages." "In the future, we will explore how to sunset the existing swift-corelibs-foundation and migrate to using the new version of Foundation created by this project."
  - astrange 3y ago
    swift-corelibs-foundation is what I meant, it contains a portable implementation of Foundation. Don't remember which parts were in Swift though.

politician 3y ago

[flagged]

Sophistifunk 3y ago
[flagged]
- jwlake 3y ago
  I mean a realistic version of that comment is that you can use GTP* to make a set of unit tests. Then iteratively write a new version in swift to be bug compliant with the old version using GPT*. Then profit? The question really is why is swift <-> objc bridge so bad you need this software?
  - coldtea 3y ago
    >The question really is why is swift <-> objc bridge so bad you need this software? HUH? I don't even understand the question. A bridge is something redundant in itself. It doesn't have to be "so bad" to want to get rid of. Why keep going through a bridge when you could (after this effort) call the lib directly? And why maintain the same code in 2 different languages, an increasingly deprecated one, and your new one?
  - liuliu 3y ago
    > The question really is why is swift <-> objc bridge so bad you need this software? Do you want to keep using a UTF-16 backed String type while the world (including Swift) is on UTF-8? (Oh, and I am posing the question to Java too...)
- keyle 3y ago
  That's a moo point anyway as Apple had put a ban on engineers using ChatGPT.
  - Smoosh 3y ago
    Clarus?

alberth 3y ago

For clarity, this is not https://www.foundationdb.org/ https://www.foundationdb.org/ Which Apple acquired years ago and then released it open source.

benatkin 3y ago
Ah, so Deno KV is using an open source database? I didn't realize that.

KingLancelot 3y ago

[dead]

SeanLuke 3y ago

[flagged]

mym1990 3y ago
What a weird usage of that word…
- commoner 3y ago
  GP was probably looking for the word "astroturfing": astroturfing: > The disguising of an orchestrated campaign as a "grass-roots" event – i.e., a spontaneous upwelling of public opinion. https://en.wiktionary.org/wiki/astroturfing https://en.wiktionary.org/wiki/astroturfing agitprop: > Political propaganda disseminated through art, drama, literature, etc., especially communist propaganda; (specifically, communism, historical) such propaganda formerly disseminated by the Department for Agitation and Propaganda of the Central Committee of the Communist Party of the Soviet Union. https://en.wiktionary.org/wiki/agitprop https://en.wiktionary.org/wiki/agitprop
  - Grustaf 3y ago
    It's obviously not astroturfing since it's a statement from Apple themselves. Astroturfing, if we were talking politics, would be if Apple secretly funded swift user groups across the world to make it appear that people liked the language. Obviously they don't have to do that, since people love it.
  - SeanLuke 3y ago
    Oh, it is astroturfing to be sure. But I was just having fun with the propaganda inherent in the sentence too.
draw_down 3y ago
[dead]
Grustaf 3y ago
Which part of the statement are you disputing? It's clearly a very successful language, with a strong community.

zainhoda 3y ago

Long overdue -- there's a very noticeable difference in runtime errors with Swift libraries vs the rest. This is especially true of AVFoundation, which is an absolute mess of hidden and undocumented state. Swift optionals and enums will go a long way to fixing that.

KerrAvon 3y ago
This will not directly affect AVFoundation, or any other framework which is not Foundation itself.
- stephen_g 3y ago
  Not as part of the work from this announcement, no, but it is surely an indication that Apple is moving in a direction where those other libraries will eventually be re-written in Swift too.
  - stephen_g 3y ago
    (Oops, I commented before looking at the link and thought it was pointing at something like this - https://www.swift.org/blog/future-of-foundation/ https://www.swift.org/blog/future-of-foundation/ - not the git repository! But you know what I mean)
saagarjha 3y ago
One of the interesting side effects of this is that those new libraries are going to have significantly worse introspection and hotpatching opportunities, so they better code them correctly, or things are going to really suck.
- ponyous 3y ago
  Would you mind to elaborate why this is the case? I am not in Swift/Obj-c ecosystem so I'm just clueless.
  - 3y ago

progrus 3y ago

I freakin knew foundation was amazing. Argh.

Xorakios 3y ago
July 14 will tell. ;)

stephc_int13 3y ago

Well, this is one more step toward a fully Swift-only platform. Very soon it will not be possible to publish an app on iOS not built with the house language. For those who don’t know, using C/C++ and opengl was easily done on iOS for many years, as llvm/clang was the official compiler.

plagiarist 3y ago
You're going to be relieved when you find out Swift has been using LLVM this entire time.
- stephc_int13 3y ago
  We’ll see. I have a bad feeling about this.
DrBenCarson 3y ago
Bad take. Swift heavily relies on LLVM. As long as you have LLVM IR, your support isn’t going anywhere. Not to mention Apple continues to be an outsized contributor to LLVM and clang (largely because they started and open sourced the projects)
- kibwen 3y ago
  Apple funds LLVM, but it didn't start LLVM. "The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages. LLVM was released under the University of Illinois/NCSA Open Source License,[3] a permissive free software licence. In 2005, Apple Inc. hired Lattner and formed a team to work on the LLVM system for various uses within Apple's development systems." https://en.wikipedia.org/wiki/LLVM https://en.wikipedia.org/wiki/LLVM
  - GeekyBear 3y ago
    Apple hired Chris Lattner straight out of college. LLVM was the subject of his Masters Thesis. It existed, but certainly wasn't yet ready for prime time. You can watch Chris give a Tech Talk at Google introducing Clang and LLVM and going over the features added in LLVM 2.0 while he was at Apple. He joined Apple in 2005. and this talk was in 2007. https://www.youtube.com/watch?v=VeRaLPupGks https://www.youtube.com/watch?v=VeRaLPupGks

endisneigh 3y ago

For a second I thought this was referring to foundationdb. Was baffled

wudangmonk 3y ago

What a dumpster fire Swift turned out to be. My first experience with it saw compile times go up more than 10x from the previous objc code base. Everytime more and more of apple's libraries were replaced because all the objc stuff was considered obsolete the compile times got worst and worst. Its not like I dislike the language either but I think compile times matter so languages should not pretend like that doesn't exist. I can forgive Rust its giving you more than just type checking but Swift does not offer the same things yet it takes just as long or longer to compile.

kitsunesoba 3y ago
While low compile times are nice I don't find them strictly necessary for the day-to-day because I'm not constantly doing full builds. Swift's incremental compiles are more than fast enough for my needs, especially on M1/Ryzen 5000 or better.
KerrAvon 3y ago
They both compile slowly because they have similarly complicated type systems. What do you use in Rust that Swift doesn’t yet provide?
- xedrac 3y ago
  Catch data races at compile time?
  - turdprincess 3y ago
    I don’t know much about Rust, but Swift can prevent data races at compile time by using the Actor type.
    - astrange 3y ago
      It could catch them before that using ownership, at the cost of lower performance. Though Swift concurrency is mostly about "concurrency" not "parallelism", which is the one that has data races.

orhmeh09 3y ago

This has been happening in public on GitHub since January, FWIW.

nixpulvis 3y ago

Still? How big is Foundation anyway? Or are we talking about the movie they released?

throwaway894345 3y ago
I think you’re thinking of the Foundation series (not movie) on Apple’s streaming service?

thrwawy74 3y ago

I just... completely don't understand the appeal of Swift beyond it being Apple's in-house language. I was excited for Foundation to become open-source. Using a language you'll really only find in 1 environment is a negative. I'm going to go feel ashamed for not getting excited about a language now. I should be celebrating "more languages", but Swift is just Apple. No one outside Apple chooses Shift unless they want to build something in Apple's ecosystem.

carbocation 3y ago
As someone who mostly writes Go, I enjoy Swift the language. I am guessing that your concerns are centered on Swift the ecosystem? (E.g., it's only used for Apple things, so there are probably not libraries for Thing X.) If so that makes total sense to me. If not, I'd be interested to hear more.
29athrowaway 3y ago
There was a lot of excitement when it first came out. I tried Swift for Linux, and soon realized it was a meh experience (NS this, NS that... NextStep is still there) and switched back to Rust. It could have been a strong Rust alternative.
- dwaite 3y ago
  That is partly what this article is about - a swift-native set of foundation modules.
  - 29athrowaway 3y ago
    Yeah but I am too invested in Rust right now
vxNsr 3y ago
While generally true that you’re not gonna find swift anywhere else, this company[0] is making their browser cross platform and using swift as the language. Apparently there’s a proof of concept runtime for windows that they’re actively working on. [0] https://arc.net/ https://arc.net/

w10-1 3y ago

The project to rewrite Foundation in Swift is many years old, and had been stalled. New in 2023 is instead NOT to match all of Foundation, but to make some core libraries that make Swift usable on many platforms. E.g., they broke out the very large internationalization/i18n tables required for unicode support into a separate module. It's very unlikely Apple would move off their own Foundation, which is well-understood and well-tested. This strategy permits them to incrementally sidle over, but continue with both for some time. Aside from servers, it's likely to look promising for multiple tiny devices - trusted computing, watches, headsets, airpods, etc.

deleted 3y ago
[deleted]
plorkyeran 3y ago
This is not the same thing as swift-corelibs-foundation, which is the old project that stalled out. The officially announced plan here is for it to fully replace the old implementation of Foundation.
- BulgarianIdiot 3y ago
  Shame really. Apple's platform has so many good ideas I wanted Swift to bring to the world as a cross-platform open-source effort. :(
  - dwaite 3y ago
    Wouldn't that be this new Swift Foundations project?
xenadu02 3y ago
This is a new effort that is committed to shipping on Apple platforms. It will also be the first time 3rd parties can get code changes into Foundation.
- saagarjha 3y ago

deleted 3y ago

[deleted]

LispSporks22 3y ago

Will it still all call send_msg and friends? Like can I still call into Foundation via C FFI or Objective C?

plorkyeran 3y ago
Yes. This is intended to be a reimplementation of Foundation with the same API, including being usable from obj-c. They've added a few compiler features recently to cover the gaps where there were some kinds of obj-c types that couldn't be defined from Swift.

ksec 3y ago

Not a popular opinion. Current Apple and Swift felt somewhat like Apple and Dylan in the 90s. May be time could tell. A lot of people hate Objective-C, and was cheering for Swift in 2014. Now nearly a decade later, it seems time and resources could have been spent somewhere else.

pjmlp 3y ago
Not really, Dylan failed to ship on NewtonOS, Swift not only is shipping across all Apple platforms, it is replacing Objective-C. Metal is the only green field framework that was still being built with Objective-C, and yet most just use the Swift bindings. Maybe Swift isn't Objective-C without C, as originally announced, but something else isn't coming to replace it either.
Grustaf 3y ago
What makes you say that? I don't think you can find many developers that would be willing to go back to Objective C.
- mpweiher 3y ago
  Not sure why the only alternative to Swift is "going back", particularly when Swift is already going back in many ways. How about going forward to an alternative that actually isn't a step back.
  - pjmlp 3y ago
    That will only happen by moving to another platform.
  - Grustaf 3y ago
    Swift is an amazing improvement over objective c and I don’t think there are any languages out there that are obviously superior for the use case. The only people i ever hear complain are objc diehards and general apple haters.
    - 3y ago

synergy20 3y ago

not an apple fan,from obj-c to swift,why not just c++, NIH plus I-want-to-control-everything?

Jtsummers 3y ago
Objective-C was not invented at Apple. Hard to see how NIH applies there.
Grustaf 3y ago
If you look at C++ and then look at Swift I think you will understand why they didn't make C++ the main language.
olliej 3y ago
Because C++ is not memory safe, lifetime safe, type safe, has notoriously brittle ABIs, ...? Seriously if you're going to take the cost of rewriting massive amounts of code, why would you not rewrite it in a language that offers actual improvements to the language that's being rewritten? Apple already has (and uses) objective-c++, and the majority of objc I've ever interacted with is objc++ once you're outside of headers (just look for .mm extensions).

karismatic 3y ago

Swift has been a hugely successfully language. Mostly at slowing down iOS runtime performance per clock cycle, and increasing compilation times. Its also been hugely successful at punishing companies for using it, since it didnt really work for a few versions. While there have been fewer crashes (sort of) due to the switch, as someone who worked for years in Objective C and years in Swift, I honestly never felt that Swift significantly improved much except allocation rituals and properties. I do however enjoy Kotlin for the backend because it has some nicer semantics for object construction. While I do admire the work that Apple has put into Swift, I really felt that Apple was trying to "impress everyone", with a whole lot of bikeshedding and sick amoutns of code generation to convince us it was the right thing to do. Frankly, apps run over 10 times faster in obj C and xcode with Swift is probably my least favorite and sort of non-ergonomic experience close to DOS batch file dev in Windows Notepad.

HacklesRaised 3y ago
Given karismatic a prize. I wonder if the current state of affairs is what Chris L had in mind?
- ihatepython 3y ago
  I don't know, but Chris L was always a C++ guy, he never really understood Objective-C in my opinion, which is why Swift ended up the way it did. I doubt he ever used it very much, or had a deep understanding of it.
  - rumori 3y ago
    I’m pretty sure Chris Lattner has a good grasp of Obj-C, after all they had to design Swift in a way it could easily interface with Obj-C. While Swift went through some versions to become stable, they were always transparent on the roadmap and had a very open attitude towards community proposals. Looking back I think it was a very well executed transition and would consider it a success in every way.
Grustaf 3y ago

gyrovorbis 3y ago

Hot-take from someone who is currently helping to port GNUStep's implementation of the Foundation framework to the Sega Dreamcast: Gross. The whole appeal of Foundation was having this incredibly convenient, beautiful, high-level object-oriented API ontop of low-level, statically compiled performant C... The true path forward for computing is clearly an alliance among the holy trinity of god's C languages: C, C++, and Objective-C. Yes, the future is in Objective-C++'s hands.

lloydatkinson 3y ago
Somehow I doubt porting MacOS to old game consoles was Apple's priority when making this decision.
- gyrovorbis 3y ago
  I'm not porting MacOS. I'm porting just the Foundation layer, and I'm not using Apple's implementation, I'm using GNUStep's. But hey, maybe having a core, foundational framework written in the most performant language out there with the most hardware support should've been a priority. ;)
ridiculous_fish 3y ago
Objective-C++ is underrated.
- gyrovorbis 3y ago
  It really is a beautiful language, and some of the most powerful aspects of Swift are due to its Objective-C roots.
xenadu02 3y ago
Foundation has not been a pure layer on top of CoreFoundation for over a decade. Some class implementations are unified on the ObjC version, not the pure C CoreFoundation version. Objective-C got good enough that all processes on Apple platforms have the objc runtime in their address space whether they want it or not and many pure C or CF-like frameworks are built on ObjC under the covers.

can16358p 3y ago

The performance "optimizations" are all about eliminating the bridge between ObjC and Swift. I'd love to see a comparison of how the functions work within their own realm, e.g.: - Speed of a date function in pure ObjC, tested in ObjC realm with no Swift bridge - Speed of the same date function in pure Swift, tested in Swift realm with no ObjC bridge. Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline.

lapcat 3y ago
> Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline. This is a strange comment, because Swift would have been Dead On Arrival in 2014 without that Objective-C bridging, an Apple-created language that doesn't work with Apple application frameworks.
- can16358p 3y ago
  Perhaps I articulated incorrectly. The bridge should have obviously existed (and should still exist for a very long foreseeable future if not forever). I was refering to having a benchmark with and without bridge and telling Swift is faster is a bit off, as that performance decrease was what Swift had to bring in the first place.
  - lapcat 3y ago
    Do you mean as some kind of Swift vs. Objective-C argument? I don't think Apple is interested in having that argument in 2023. There's no point. Swift has won the "language war", politically within Apple and in developer mindshare outside Apple. (I say this as someone who continues to write Objective-C.)
    - can16358p 3y ago
      Nope, Swift clearly won (which was created by Apple themselves to replace ObjC in most places if not all eventually). I think the metrics in their current form don't really mean much if it's only measuring the performance "gain" by getting rid of the ObjC/Swift bridge.

wildpeaks 3y ago

The Swift feature I miss in other languages is `enum` cases with parameters and `switch` blocks having to cover all cases, it's so convenient.

bsaul 3y ago
same here. I don't understand how this feature hasn't landed in every other compiled languages (i'm looking at you golang)
dwaite 3y ago
Both of these are also shared with Rust FWIW. I believe Swift takes the switch farther than match in Rust, because it tries to deal with API stability (e.g. a system library adding new possible cases)
dontlaugh 3y ago
Proper sum types are so useful, it's a tragedy so many statically typed languages lack them.

tagyro 3y ago

I might be in the minority here (though, reading the comments, it seems others have the same opinion), but I find Swift to be a step back compared to Objective-C. I really like the verbosity of Objective-C - this makes the code more readable and easier to understand, even (or especially) when reading a program the first time. Being a superset of C (and C++ with Objective-C++) means that, when necessary, one can easily write a C (or C++) method (or class) but also include existing C/C++ libraries. I also find some of the improvements Swift brings to actually make developers more reckless and dependent on the language/compiler (yes, I liked to manually manage memory). And a bit of a personal frustration: I find a swift package/project that I want to use, download it and ...start fixing/updating the code, so that it compiles with the latest Swift version. I still have Objective-C code I wrote more than 10 years ago that compiles and runs with minimal or no change.

lapcat 3y ago
> yes, I liked to manually manage memory I think you are in the minority there, even among Objective-C programmers. In any case, Objective-C ARC is there for those who want it.
s_dev 3y ago
>I might be in the minority here I think for sure you're in the minority here. Swift was really a breath of fresh air for my iOS dev work -- it's just so modern and easy to read. That said -- I'm still reluctant on SwiftUI though. Seems like one of those technologies that works great for small apps and tutorials but falls apart at scale but admittedly have little experience with it so perhaps I'd be wise to reserve judgement.
- rumori 3y ago
  I’m with you on the SwiftUI skepticism. After 10+ years of native iOS development - can’t believe I’m saying this - but I thoroughly enjoy Flutter, it’s open source I can easily modify anything I want, the tooling is great, VS Code plugin is great, and hot reloading a live app is just amazing. It’s everything SwiftUI should be, let’s see what new stuff they announce at WWDC.
3y ago