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

41–50 of 402 posts

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

#41

Post by manmal »

ChrisMarshallNY wrote: post #38

This will take a while, but I'm looking forward to it. It's probably another big step towards "Swift everywhere," without worrying about bridging to C. I've been doing little but Swift since 2014, and really like the language. I'm still "on the fence" about SwiftUI, but that's mostly because of the level of support from Apple, and the [im] maturity of the system. This will help with that.

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

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

#42

Post by klodolph »

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…

Somebody rewrote an app in Swift -> the app is slower.

Somebody rewrote a library in Swift -> the library is faster.

There's a lot to talk about and unpack here. My experience is that people develop a different mindset when they do library development, because any code that they write will be code that they're forced to support for decades to come. You put bad code in an app and you can simply rip it out with the next revision, no questions asked. So you are much more likely to end up with questionable code in an app than in a library.

I'm also old enough to remember not only the same complaints when people were rewriting apps into Objective C (lots of early Mac OS X apps were Carbon, including Finder), but when the same complaints were made about rewrites from assembler into C. Every decade your computer has a hundred times more computing power and your code takes 10x as much footprint, so you come out ahead, on average. It's just that any given year you might come out behind.

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

#44

Post by dcow »

etse wrote: post #39
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.

How would you compare Swift with Kotlin in terms of being a good stand-in for high-level Rust? I've not paid attention to Kotlin in a while, but it seems like there's more progress at supporting Kotlin across more platforms (Kotlin native, web?, etc). I'm curious if people feel that the language features and design are at about parity, or if one is significantly stronger/weaker.

I haven't seriously used Kotlin in 4-5 years. I too was excited about it supporting native compiles and web assembly but I have no firsthand experience with how far those efforts got.

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

#45

Post by dcow »

eatonphil wrote: post #40
etse wrote: post #39

Earlier quoted context omitted.

How would you compare Swift with Kotlin in terms of being a good stand-in for high-level Rust? I've not paid attention to Kotlin in a while, but it seems like there's more progress at supporting Kotlin across more platforms (Kotlin native, web?, etc). I'm curious if people feel that the language features and design are at about parity, or if one is significantly stronger/weaker.

Swift has the distinction (for better and worse) of not being tied to the JVM.

Kotlin-native is an effort to compile directly to your target non-jvm machine.

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

#46

Post by manmal »

etse wrote: post #39
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.

How would you compare Swift with Kotlin in terms of being a good stand-in for high-level Rust? I've not paid attention to Kotlin in a while, but it seems like there's more progress at supporting Kotlin across more platforms (Kotlin native, web?, etc). I'm curious if people feel that the language features and design are at about parity, or if one is significantly stronger/weaker.

Last time I toyed with Kotlin Multiplattform (bit less than a year ago) it provided only really weird Objective-C bindings for use in iOS/macOS. Like, a statically defined List turned into an Obj-C iterator. Enum and sealed classes were quite problematic either - I honestly would not consider using KMM for anything but a PoC.

BTW, JetBrains recently sunsetted AppCode, so they are bleeding their Swift talent now. I suspect that doesn’t bode so well for Kotlin‘s Swift interop.

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

#47

Post by rattray »

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.

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?

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

#48

Post by rattray »

kitsunesoba wrote: post #27
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 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.

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

#49

Post by ChrisMarshallNY »

manmal wrote: post #41
ChrisMarshallNY wrote: post #38

This will take a while, but I'm looking forward to it. It's probably another big step towards "Swift everywhere," without worrying about bridging to C. I've been doing little but Swift since 2014, and really like the language. I'm still "on the fence" about SwiftUI, but that's mostly because of the level of support from Apple, and the [im] maturity of the system. This will help with that.

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 includes that awful JS TVOS system), so I am a big proponent of real native apps.

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

#50

Post by mpweiher »

KerrAvon wrote: post #14
mpweiher wrote: post #8

Earlier quoted context omitted.

Things will get even slower.

Available data so far seems to show that the pure Swift implementations are faster than the Objective-C ones even when called from ObjC clients. I don't have a link, so feel free to treat as hearsay, but FYI.

You don't have a link to the data because this is not true.

Swift is generally slower than Objective-C, often significantly so. There are cases where it is faster, but those are rare.

Yes, I have measured.

One example is JSON and Swift codable, which is comically slow, see:

Somewhat Less Lethargic JSON Support for iOS/macOS, Part 1: The Status Quo

https://blog.metaobject.com/2020/04/somewhat-less-lethargic-...

Punch line: Swift codable does around 10MB/s, despite all the supposed performance goodies and compiler support everyone always talks about and nobody appears to ever measure. A pure Objective-C implementation does 284MB/s.

I also did a more general survey for my book[1]. While that's been a while, I haven't seen any indication that things have fundamentally changed, and lots of indications that they haven't.

Post reply on HN