Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple announces full Swift rewrite of the Foundation framework (2022)

infoq.com

Post reply on HN
Print view View original

51–60 of 402 posts

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#51

Post by saagarjha »

avisser wrote: post #35
mplewis9z wrote: post #23

Earlier quoted context omitted.

> my impression is that the support on Linux within the Foundation is not complete It is not, but it's like 95% of the way there in my experience - most things that are missing are relatively recent additions that have some complex OS interactions, like filesystem I/O with language-level concurrency features. > Does this change imply better (eventual) support on non-Darwin systems? Yes. The non-Darwin Foundation vers…

It feels off to call things like Array part of any library when you have array literal syntax `let oddNumbers = [1, 3, 5, 7, 9, 11, 13, 15]` I'd call that a language feature. Or maybe with Swift there is a blurry line between the two?

Arrays are part of the Swift standard library. Foundation is another library that provides access to things like I/O, networking, calendars, etc.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#52

Post by pkulak »

eatonphil wrote: post #12

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.

Swift is great because it's the only alternative to Objective C. I don't really think anyone is clamoring for it to move into non-Apple domains.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#54

Post by mpweiher »

klodolph wrote: post #26
mpweiher wrote: post #8

Earlier quoted context omitted.

Things will get even slower.

Just to explain why Objective C code, in practice, is not especially fast: You generally make the choice between writing something in pure C, which gives you plenty of performance but little safety, or using Objective C classes and methods, which gives you plenty of safety but you're paying the price for dynamic dispatch (objc_msgSend) and pointer indirections all the time. Swift makes it easier to eliminate things l…

While this is what a lot of people believe, it happens to not be true.

For more details, see iOS and macOS Performance Tuning: Cocoa, Cocoa Touch, Objective-C, and Swift, Addison-Wesley

https://www.amazon.com/iOS-macOS-Performance-Tuning-Objectiv...

If you don't want to read a book, here is an example as a series of blog posts: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-...

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#55

Post by davidkuennen »

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.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#56

Post by ChubbyGlasses »

dcow wrote: post #20

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.

Swift and Carbon both seem like very strong contenders in this space. Swift is already a really strong language albeit a little too tied to Apple’s ecosystem. This along with the ownership manifesto slated for Swift 6 (and C++ interop) should make it easier to use it everywhere. In particular, I see a lot of value for tooling (eg JS code bundlers and such) that are rewritten in “thinner” languages for performance needs without sacrificing developer productivity.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#57

Post by machinekob »

birdymcbird wrote: post #36

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?…

It's a lot of obj-c/c on apple and syscalls on other platforms, I think the biggest point its to get rid of annoying obj-c calls and make it fully cross platform as its a nightmare for both safety and performance in many cases to call objc.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#58

Post by pkulak »

dcow wrote: post #20

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.

I don't know if you can write high-throughput systems with 100% reference counted GC. Swift is targeted at UI work pretty hard.

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#59

Post by ofcourseyoudo »

wlesieutre wrote: post #3

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

Re: Apple announces full Swift rewrite of the Foundation framework (2022)

#60

Post by saagarjha »

dilap wrote: post #37
klodolph wrote: post #26

Earlier quoted context omitted.

Just to explain why Objective C code, in practice, is not especially fast: You generally make the choice between writing something in pure C, which gives you plenty of performance but little safety, or using Objective C classes and methods, which gives you plenty of safety but you're paying the price for dynamic dispatch (objc_msgSend) and pointer indirections all the time. Swift makes it easier to eliminate things l…

In practice would be what the resulting apps turn out like. In my experience, old-school ObjC iOS and Mac apps generally tended to be quite snappy. On the other hand, the new Swift hotness of Messages and Settings on macOS are noticably slower than what they're replacing. Of course I haven't done a comprehensive inventory, but I certainly don't have the general impression of things getting faster with Swift. (Are the…

Messages is largely an Objective-C codebase.
Post reply on HN