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.

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.

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

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.

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.

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.

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.