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.
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.
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.
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.
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.
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.
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.
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.
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.
While it’s true that the language is really only useful on just Apple platforms, it is still quite an amazing language. I have professionally used about half a dozen languages over the last many years, written hundreds of thousands of lines each in all those languages, and swift is a true breath of fresh air. It checks all the boxes for me, very concise and elegant to write, yet very strictly statically typed. A nice upgrade to OO programming with use of protocols, with strong encouragement to use functional programming here and there as well. Runs reasonably fast, on par with Go or Java. Overall just really nice ergonomics. named parameters and a wide variety of other seemingly minor syntactical characteristics act as a meaningful upgrade to make the overall process of writing code much more enjoyable for me.
The fact that Apple provides all these incredible platform specific frameworks and libraries for graphics, audio, games, GPU kernel programming, and more, it’s just the icing.
How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc.
Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of the argument at compile time, so copying the arguments has to be dynamically dispatched unless the compiler can figure it out in an extra optimisation pass...that's not possible when doing separate compilation.
> Runs reasonably fast, on par with Go or Java.
A downgrade...particularly considering the epic compile times.
Having to deal with weakself, no reference cycles, very limited closures, having to deal with Xcode, no integration with any other IDE because Apple Apples, debatable generics, SPM, debatable cross platform abilities, fucking Tasks and Actors, SwiftUI being locked to versions of Swift, extremely limited community, few high quality open source libraries for something that only performs as well as Java is quite the hard sell.
For that price, you could also get Kotlin which fixes most of Java's problems and provides access to all the JVM as well as Kotlin/Native, with top tier DSL abilities and a really well thought out stdlib, coroutines, reified funs and much more.
IBM briefly did a "swift on the server" though at the beginning of 2020 IBM was no longer interested, but the page is still up. https://developer.ibm.com/languages/swift/
My experience was the opposite, I really like Swift but its usefulness is held back by the lack of a wider community. I'm not sure if that's due to a lack of investment on Apple's part, or maybe that it lives in an unhappy compromise between C++ and Python where there's always a more mature alternative that's good enough, but the language itself is quite nice to write.
If they just had a proper cross platform standard library and package manager it might be more successful, it is a pretty cool language. But the north Korean esque closed apple ecosystem makes that impossible, all of that is intentional.
Why is it not better for Apple to make Swift truly cross-platform?
Is it just that the maintenance cost is not worth it? Or would it threaten its ecosystem in a way that I don't understand?
It would seem that making Swift cross-platform would make Apple's ecosystem more accessible to developers. The barrier to entry would be lower if developers only needed to learn the APIs and not a whole new language and its tooling too. This would help the ecosystem stay healthy for a longer time.
Totally valid point that swift is only useful for developing for Apple products, but this same criticism also applies more or less to Kotlin on Android. If you are dealing with iOS it is a joy compared to objective C. I would also add that it is a really nice language in general that is modern, expressive and general ergonomic.
> this same criticism also applies more or less to Kotlin on Android.
i think kotlin has more use outside compared to swift.
But a language has to start somewhere, so i wouldn't hold it against swift. It's a fairly well done language regardless, and nothing apple specific about it tbh (which are all just libraries).
I think many also find its syntax more approachable compared to that of Rust. It's got a lot of bells and whistles, but newcomers don't have to use them right away and can pick up more advanced bits as they become comfortable with doing so.
You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect.
Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.
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.
You got a point. On the other side, arguably, one could say the same about C#, JavaScript or Python.
It took real effort from Microsoft into the Open Source space to make it more widely popular. Far away from Java or JavaScript, but I see many similarities between the development and evolution of Swift and C#.
Almost everything starts as a domain specific language. Same goes for JavaScript. First browser only, then through Node, suddenly JavaScript everywhere.
Python gained massive traction through Jupyter. Before that, I found Python a clumsy alternative to JavaScript. Since then I have changed my mind. ;)
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.
> No one outside Apple chooses Shift unless they want to build something in Apple's ecosystem.
“No one”
Yet The Browser Company (The one that is hyping the Arc Browser) is writing their browser in Swift to support Windows. [0] which that is their main product.
EDIT: So this video doesn't show someone choosing Swift outside of Apple and using on a different platform (Windows) and doesn't disprove the claim of "No one outside Apple chooses Swift"?
Surely you can do better than some of the very low effort replies below.
The Browser Company is absolutely no one. They're barely more influent than me creating a repo on github, and that kind of impact is pretty damn low as is. They're a 0.000% browser share company that runs a tight marketing campaign of only inviting tech influencers to their browser. Mind you, said browser has good ideas, great ones even. But overall, they're absolutely no one.
iOS/macOS devs use Swift on other platforms because it's the only language they know, yeepidodadey. Ignore the fact that 99% of their project is cinterop with Chromium
You're saying two things as if they're a contradiction, but they aren't
It's valuable to Apple to have a language perfectly tuned to their stack, as the official entrypoint to all their APIs. If you need to use those APIs, you're excited about Swift. If you don't, you aren't
The same appeal as .NET on the Windows ecosytem, Objective-C on NeXT/OS X, Java/Kotlin on Android (plenty of stuff that is Android only beyond the basic standard library, C++ OS specific SDKs,....
Many people are more than happy to do all their career on a specific platform.
Not really. The two are somewhat sister languages, but they have been syntax-optimized toward completely different focuses.
Swift for example defaults to copyable value types and reference types that are refcounted because that is what is most often needed for evented application code, while Rust defaults to non-copyable objects (with wrappers for things like reference counting) because of its systems development focus.
Swift also had a hard requirement of a decade of co-existance with Objective-C. A significant number of Swift types toll-free bridge with objc (and corefoundation) alternatives, and that had a considerable impact on the standard library. Their base library would be different from Rust's "std" due to needing different implementations of strings, vectors, dicts and so on.
The two do take quite a bit of inspiration from one another, and will gradually grow to support an ever-larger overlapping set of use cases, but the design constraints of the existing language will still mean that one or the other is better for a specific task.
No, that's not possible. Just one example -- In Rust/C++, developer is responsible for managing the memory, while in Java/Swift etc the language does most of the work for you. This alone can fundamentally change many aspects of language design and mean completely different experience for developers
The appeal of swift is that it is lightyears better than ObjectiveC. To ObjC developers that are used to being treated like trash by Apple (abysmal documentation, stone age IDE and tooling etc) that's huge
Apple's documentation was actually vastly superior before Swift. In fact, I often refer to the documentation "archive" instead of the latest docs.
The decline in the docs is due to a number of factors, but I would say mainly it's (1) the relentless annual major OS update schedule, (2) the proliferation of OS (macOS, iOS, watchOS, tvOS, xrOS?), (3) the dual language stack, (4) Apple personnel turnover.
I do quite like Swift overall -- it’s usually terser than Obj-C and I like the much stricter and more expressive type system. But you pay for that with much longer compile times, and the tooling feels much the same (Xcode is still Xcode).
There's not even anything technically interesting about the language. Reference counting? Really? We have so much more than that and you just went with reference counting. Ugh
> There's not even anything technically interesting about the language
It's a modern statically compiled language with complex generics, that supports providing a generic interfaces in libraries with retaining ABI compatibility. Which no other modern "system" language supports. That's fairly technically interesting to me.
> We have so much more than that and you just went with reference counting
Like what?
The options for memory safe shared ownership are refcounting or GC.
Assuming you're talking about rust, that's just C++: object lifetime is lexical, and if you need it to last longer you have to use Arc/Rc/shared_ptr. The purpose of the lifetime and borrow checkers is to ensure exclusive access, and reduce the copy/destruction churn that you get from the C++ model (a hypothetical C++ that only allows the use of unique_ptr instead of raw pointers - obviously C++'s type system and approach to memory safety is not a Good Thing).
But it's important to realize rust did not create a new solution to object lifetime management for shared objects.
It's also important to realize that rust was designed in an environment where there was no existing code to interoperate with, whereas Swift was designed to work with the existing Darwin APIs and objective-c which are all refcounted. So even if no refcounting was the goal you'd end up with a new language, designed for a specific environment, and the default behaviour would not be correct.
Now that the language is more established, and it's less critical for every part of the language to have objc interop they are working on pure ownership semantics, for the same reason as rust: it saves copies without requiring a refcount[1]
What would you use instead of ref counting? Swift is an embedded language for Apple’s own chips, they can optimize the hell out of refcounting at silicon level.
Seems a lot of people feel the way you do. I had to make something using swift once, and could barely find a community to help me decipher the cryptic swift documentation centered around their coreml library. Apple is keeping Swift on life support, imo.
CoreML is a bit of an exceptional challenge beyond just Swift. Admittedly it could really use a lot more documentation from Apple, but it would be unfair to judge swift based on an uncommon and under documentated library (I suspect that it would get a lot more use if it were not so hard to set up).
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.
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".
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.
> 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."
> 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.
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.
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.
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.
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.
Readit News
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 Comment
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.
I wonder if the current state of affairs is what Chris L had in mind?
Dead Comment
The fact that Apple provides all these incredible platform specific frameworks and libraries for graphics, audio, games, GPU kernel programming, and more, it’s just the icing.
How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc.
Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of the argument at compile time, so copying the arguments has to be dynamically dispatched unless the compiler can figure it out in an extra optimisation pass...that's not possible when doing separate compilation.
> Runs reasonably fast, on par with Go or Java.
A downgrade...particularly considering the epic compile times.
> named parameters
Also there since the 80s, in a less weird way.
https://blog.metaobject.com/2020/06/the-curious-case-of-swif...
> ...professionally used about half a dozen languages ...
What languages were those, if I may ask?
Having to deal with weakself, no reference cycles, very limited closures, having to deal with Xcode, no integration with any other IDE because Apple Apples, debatable generics, SPM, debatable cross platform abilities, fucking Tasks and Actors, SwiftUI being locked to versions of Swift, extremely limited community, few high quality open source libraries for something that only performs as well as Java is quite the hard sell.
For that price, you could also get Kotlin which fixes most of Java's problems and provides access to all the JVM as well as Kotlin/Native, with top tier DSL abilities and a really well thought out stdlib, coroutines, reified funs and much more.
2016: https://9to5mac.com/2016/02/22/ibm-swift-cloud-kitura/
2016: https://www.infoq.com/presentations/swift-server/
2020: https://www.infoq.com/news/2020/01/ibm-stop-work-swift-serve...
You can run it in docker: https://hub.docker.com/_/swift
for now
just saw an article about IBM deleting most of their website because its a mess. It was some linkedin developer's post.
It is the most similar in terms of language features and style but it has access to Java's unparalleled library and tooling ecosystem.
The standard library is becoming cross-platform as we discuss it here.
Is it just that the maintenance cost is not worth it? Or would it threaten its ecosystem in a way that I don't understand?
It would seem that making Swift cross-platform would make Apple's ecosystem more accessible to developers. The barrier to entry would be lower if developers only needed to learn the APIs and not a whole new language and its tooling too. This would help the ecosystem stay healthy for a longer time.
It was JetBrains pet project to fix archaic stuff in Java without making a Scala. It was designed from the get go for a wide base (as wide as java).
I'm not sure how it became Android's main target, but I doubt it was the original purpose.
i think kotlin has more use outside compared to swift.
But a language has to start somewhere, so i wouldn't hold it against swift. It's a fairly well done language regardless, and nothing apple specific about it tbh (which are all just libraries).
It's like Rust in that it offers memory safety by default without a big performance hit.
You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect.
Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.
[0] https://arc.net/
It took real effort from Microsoft into the Open Source space to make it more widely popular. Far away from Java or JavaScript, but I see many similarities between the development and evolution of Swift and C#.
Almost everything starts as a domain specific language. Same goes for JavaScript. First browser only, then through Node, suddenly JavaScript everywhere.
Python gained massive traction through Jupyter. Before that, I found Python a clumsy alternative to JavaScript. Since then I have changed my mind. ;)
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.
“No one”
Yet The Browser Company (The one that is hyping the Arc Browser) is writing their browser in Swift to support Windows. [0] which that is their main product.
The Browser Company is not “No one”.
[0] https://m.youtube.com/watch?v=Xa_fNuaSE_I
EDIT: So this video doesn't show someone choosing Swift outside of Apple and using on a different platform (Windows) and doesn't disprove the claim of "No one outside Apple chooses Swift"?
Surely you can do better than some of the very low effort replies below.
iOS/macOS devs use Swift on other platforms because it's the only language they know, yeepidodadey. Ignore the fact that 99% of their project is cinterop with Chromium
It's valuable to Apple to have a language perfectly tuned to their stack, as the official entrypoint to all their APIs. If you need to use those APIs, you're excited about Swift. If you don't, you aren't
Many people are more than happy to do all their career on a specific platform.
Dead Comment
And not at all compatible or easily bridgeable with obj-c, which was not optional.
Swift for example defaults to copyable value types and reference types that are refcounted because that is what is most often needed for evented application code, while Rust defaults to non-copyable objects (with wrappers for things like reference counting) because of its systems development focus.
Swift also had a hard requirement of a decade of co-existance with Objective-C. A significant number of Swift types toll-free bridge with objc (and corefoundation) alternatives, and that had a considerable impact on the standard library. Their base library would be different from Rust's "std" due to needing different implementations of strings, vectors, dicts and so on.
The two do take quite a bit of inspiration from one another, and will gradually grow to support an ever-larger overlapping set of use cases, but the design constraints of the existing language will still mean that one or the other is better for a specific task.
That's like...Apple's whole deal. Proprietary everything top-to-bottom.
The decline in the docs is due to a number of factors, but I would say mainly it's (1) the relentless annual major OS update schedule, (2) the proliferation of OS (macOS, iOS, watchOS, tvOS, xrOS?), (3) the dual language stack, (4) Apple personnel turnover.
I do quite like Swift overall -- it’s usually terser than Obj-C and I like the much stricter and more expressive type system. But you pay for that with much longer compile times, and the tooling feels much the same (Xcode is still Xcode).
It's a modern statically compiled language with complex generics, that supports providing a generic interfaces in libraries with retaining ABI compatibility. Which no other modern "system" language supports. That's fairly technically interesting to me.
> We have so much more than that and you just went with reference counting
Like what?
The options for memory safe shared ownership are refcounting or GC.
Assuming you're talking about rust, that's just C++: object lifetime is lexical, and if you need it to last longer you have to use Arc/Rc/shared_ptr. The purpose of the lifetime and borrow checkers is to ensure exclusive access, and reduce the copy/destruction churn that you get from the C++ model (a hypothetical C++ that only allows the use of unique_ptr instead of raw pointers - obviously C++'s type system and approach to memory safety is not a Good Thing).
But it's important to realize rust did not create a new solution to object lifetime management for shared objects.
It's also important to realize that rust was designed in an environment where there was no existing code to interoperate with, whereas Swift was designed to work with the existing Darwin APIs and objective-c which are all refcounted. So even if no refcounting was the goal you'd end up with a new language, designed for a specific environment, and the default behaviour would not be correct.
Now that the language is more established, and it's less critical for every part of the language to have objc interop they are working on pure ownership semantics, for the same reason as rust: it saves copies without requiring a refcount[1]
[1] https://github.com/apple/swift/blob/main/docs/OwnershipManif...
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.
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
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.
And all the money in world can't make it any faster.
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."
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.
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.
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.
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.
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.
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.
Dead Comment
Which Apple acquired years ago and then released it open source.