Live data from Hacker News

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

infoq.com

61–70 of 402 posts

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

#61

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

Most of Foundation on Darwin used to call into Objective-C code. This is going to be replaced with Swift code while keeping the API the same.

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

#62
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.

Afaik Swift is pretty close to using Rc and Arc everywhere. Does swift do some more escape analysis than Rust?

Swift only uses reference counting when working with objects; Structs are optimised using copy-on-write. There's currently work on implementing move and ownership semantics, similar to Rust, but opt-in rather than by default.

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

#63
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.

Afaik Swift is pretty close to using Rc and Arc everywhere. Does swift do some more escape analysis than Rust?

I haven’t read that much on Rust, but that should be pretty much it.

Swift has an emphasis on value types, which often are stored on the stack, but only up to a certain size. Copy-on-write makes this feasible - often, those value types are passed by reference until a write actually occurs, but that’s opaque to the dev. Value types can have pointers to reference-counted types - if a value type is passed/copied, any pointer it owns is retained (weirdly enough, they claim that value types have no „lifetime“, but at some point those refs have to be released - we just have to trust the compiler in this).

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

#64

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…

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-...

I read the blog post, but it just seems to provide a single example of a case where some particular piece of Objective C code was faster than the equivalent piece of code in Swift. Maybe there's something I'm missing here... what should I be looking for in these blog posts?

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

#65

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.

[deleted]

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

#66

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.

Apple’s style reminds me a lot of something I once read (and later experienced) about Japan and tourism:

> (roughly) Japan is a country for the Japanese. While they may welcome you and invite you to experience their country and culture, the country is very much setup to serve the Japanese populace.

Apple feels similarly. They build what they need and enough to capture the revenue they want, but I don’t perceive them to really cater to external needs beyond what will monetize.

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

#67
post #41

Earlier quoted context omitted.

Yes, and it means Swift scripts and modules that don’t reference UIKit/AppKit/SwiftUI/Combine will run on Linux and possibly Windows with zero or little modification. I‘m a little sad though that they didn’t start this endeavor years ago, because IMO Rust has already built so much momentum that it will win (for the popular, medium to long term definition of „winning“).

I don't particularly care, whether or not Swift ever leaves the Apple ecosystem (like ObjC). In that domain, Rust will never "win." I think that Rust is an awesome server language, though, and I'm glad to see it gain traction. I just hope that it doesn't get trashed by a bunch of junk dependencies, written in it. I find using apps written, using hybrid systems, or PWAs, to be quite painful (on Apple devices -and that…

I think whoever „wins“, it would be necessary to have good interop at least. Currently, Rust devs are integrating core libs into native iOS apps by going the C route. All this work to make everything memory safe, and then this.

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

#68
post #48

Earlier quoted context omitted.

I would love to be able to write cross-platform desktops apps in Swift. The language isn't perfect of course but I enjoy it a lot more than the alternatives I've tried. That possibility is still a ways down the road of course but Foundation getting a cross platform rewrite is a nice step in that direction.

If you or others on this thread are interested in working on a Swift compiler for Windows, please reach out to me :) a good friend is hiring a team to make this happen.

How will that be different from Apple’s Swift toolchain for Windows (https://www.swift.org/blog/swift-on-windows/)?

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

#69
post #52

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.

I know I do. Swift is an amazing language, truly.

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

#70
post #47
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.

Interesting. Asking as someone who's never programmed with Swift or Rust, but is familiar with the syntax/ideas of each, I'm curious why you say that?

If you don't care about performance and "zero cost abstractions" and are more interested in Rust for its memory safety, then most of your Rust programs end up with a lot of syntactic and library bloat to add those "costly" (but convenient) abstractions back in, like explicitly cloning or wrapping types in Rc and Arc or just always taking ownership of borrowed data by constructing owned types with it. And then there are lifetimes which can be and are elided in almost all uses cases so they're ultimately just confusing whenever you actually have to deal with them. C.f. Swift, where the default is in my experience what "higher level" rust programs end up looking like, but with much nicer and cleaner syntax. And Swift has a very nice rather memory safe API for calling into C or otherwise just generally accessing scoped pointers when needed. This same api can actually be used to expose more performant apis to underlying data etc. when needed. It's kinda the reverse of Rust.

It feels like Rust is two languages in one: a high performance zero cost abstraction language that tracks pointer ownership, and a package rich and hyper explicit application language build atop all the guts. That's why I say high-level application use cases, because most high-level applications are not concerned with raw performance but rather with functionality and user experience. The parts that are concerned with throughput can be implemented using tooling where those knobs are available. I have enjoyed writing a cli and api server and various libraries in Rust. But every so often I am left wondering when Swift might be able to replace it for my higher level concerns. Alternatively, it would be neat to see some effort put behind a "convenient rust" type of compile mode for modules where you could compile with things like implied clones, unified owned vs reference types, auto-arc/box, etc.

Post reply on HN