Live data from Hacker News

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

infoq.com

251–260 of 402 posts

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

#251

Who else remembers when they re-implemented the (at the time version of) the Foundation framework in Java for WebObjects? That was, what, 1998? Right around when NeXT got re-absorbed by Apple, not sure if the rewrite was started before or after. https://developer.apple.com/library/archive/documentation/Le... https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-... Those were the days! Actually kind of amazing…

Foundation was developed for the needs of EOF so it makes sense there was a version for the Java WebObjects. There's almost certainly NeXT-derived code in macOS/iOS with a longer pedigree and a bunch of it will probably outlast the Foundation rewrite. As software evolution goes, it's an astonishingly long run, no doubt. Especially for a technology that very nearly went extinct.

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

#252
post #58
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.

Sure you can. C++ has reference-counted garbage collection with its smart pointers and RAII, just like Swift. People certainly write high-throughput systems in C++.

Swift is slower than C++, yes, but not because of its memory management scheme.

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

#253
post #251

Who else remembers when they re-implemented the (at the time version of) the Foundation framework in Java for WebObjects? That was, what, 1998? Right around when NeXT got re-absorbed by Apple, not sure if the rewrite was started before or after. https://developer.apple.com/library/archive/documentation/Le... https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-... Those were the days! Actually kind of amazing…

Foundation was developed for the needs of EOF so it makes sense there was a version for the Java WebObjects. There's almost certainly NeXT-derived code in macOS/iOS with a longer pedigree and a bunch of it will probably outlast the Foundation rewrite. As software evolution goes, it's an astonishingly long run, no doubt. Especially for a technology that very nearly went extinct.

Huh, Foundation was developed for EOF? (Enterprise Object Framework; it was actually very much like Rails ActiveRecord). I did not realize that, I always figured it came first.

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

#254

Earlier quoted context omitted.

"It's not Objective-C" is pretty much the only advantage it has. You're not missing anything, it's basically a superfluous language that only exists in its current form because Objective C needed replacing and Apple would never adopt a language they didn't have effective control over. Language-wise, I see zero benefit over Rust, possibly Go (I'm not familiar enough to comment) or even JVM-less Kotlin. But hey, we're…

Static and concise NPE protection via optional syntax, and the guard construct, both make defensive programming much easier in Swift. Tons of other little things. Memory management is easier than it is in Rust. It has generics which makes it more flexible than Go [was until its generics were recently introduced]. Kotlin native wasn’t announced until three years after Swift. I don’t think it’s as simple or one-sided a…

I don't consider this:

guard let foo = bar else { ... }

to be any better than this:

if bar().is_none() { ... }

For the record, I find the guard keyword totally unnecessary and I still have NFI what's wrong with this in Swift:

if bar == nil { ... }

I also totally disagree about memory management being "easier" (at least with C-interop), because I think Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all.

To be clear though: I don't think Swift is a bad language. It's perfectly adequate. But it's the fact that Apple decided to force Yet Another Programming Language down our throats that, in my opinion, offers no real advantage over many of the other choices available at the time.

"We're Apple and you will only use a language that we control" was, IMO, the driving force behind Swift, not the inherent superiority of the language itself.

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

#255
This is pretty alarming.

I don't think Apple can do a full rewrite of Foundation, unless its opt-in only for Swift apps that have been ported to the new Swift-only codebase. If they are trying to opt in non-Swift apps, well, I'm glad I don't use OSX nor have to support it.

The article linked has few details on how they plan to do this, or how they plan on limiting the blast range.

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

#256

Who else remembers when they re-implemented the (at the time version of) the Foundation framework in Java for WebObjects? That was, what, 1998? Right around when NeXT got re-absorbed by Apple, not sure if the rewrite was started before or after. https://developer.apple.com/library/archive/documentation/Le... https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-... Those were the days! Actually kind of amazing…

I thought it was NeXTSTEP/Sun, but it seems disputed. https://stackoverflow.com/questions/473758/what-does-the-ns-...

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

#257
post #251

Earlier quoted context omitted.

Foundation was developed for the needs of EOF so it makes sense there was a version for the Java WebObjects. There's almost certainly NeXT-derived code in macOS/iOS with a longer pedigree and a bunch of it will probably outlast the Foundation rewrite. As software evolution goes, it's an astonishingly long run, no doubt. Especially for a technology that very nearly went extinct.

Huh, Foundation was developed for EOF? (Enterprise Object Framework; it was actually very much like Rails ActiveRecord). I did not realize that, I always figured it came first.

I don't have a better reference than 'stuff I heard from people who worked on EOF'. The EOF Wikipedia page puts like this:

EOF 1.0 was the first product released by NeXT using the Foundation Kit

One way or the other, their development was closely connected/overlapping.

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

#258

This is pretty alarming. I don't think Apple can do a full rewrite of Foundation, unless its opt-in only for Swift apps that have been ported to the new Swift-only codebase. If they are trying to opt in non-Swift apps, well, I'm glad I don't use OSX nor have to support it. The article linked has few details on how they plan to do this, or how they plan on limiting the blast range.

[deleted]

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

#259
post #227

Earlier quoted context omitted.

Reading the super majority of Rust code is equally easy or easier than reading Python, or Typescript, or even Ruby. Writing Rust applications is also very ergonomic. The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks. The only Rudy lacking ergonomics is writing net new frameworks or missing framework pieces, or when std is not available. 95%+ of all new Rust code will fa…

This isn't really the case. Rust code is almost as complex as C or C++ for any non-trivial application.

That’s just not true. Just the fact that you can reuse libraries easily makes Rust much easier. That combined with memory safety means that the two biggest headaches of C and C++ are just gone.

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

#260
When the product of this hits the OS I predict massive instability. I don't think the Apple of 2022 has the level of systems programming talent that was behind the 1990s code in the core foundation. Today I feel like most of their attempts to move the OS forward beyond the shiny UI gimmicks (Tired of Exposé™? Try Stage Manager!™) are sloppy and only barely work (like "discoveryd" - google that if you don't remember).

If you don't believe me, quit all your non-Apple apps, and open up Console.app and hit Start streaming, and limit only to the "Errors and Faults" and watch the computer scream in logs until you're convinced. This is what modern Apple software quality looks like. I really don't want them touching anything near the core OS. Especially because when Apple software doesn't work, either you'll get no feedback, or it will say something comically vague like, that it "can't be completed."

I'd LOVE to be proven wrong here because otherwise I'll have to finally catch up on my Windows knowledge and get used to not having a GUI metakey separate from Ctrl!

Post reply on HN