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

Apple is rewriting Foundation in Swift

github.com

Post reply on HN
Print view View original

131–140 of 263 posts

Re: Apple is rewriting Foundation in Swift

#131

Post by [deleted] »

stevefan1999 wrote: post #120
kevingadd wrote: post #65

Earlier quoted context omitted.

From what I've seen the ref counting can cause a big performance hit. Maybe this has improved in the last couple years?

Reference counting is slow because it has an additional increment/decrement operator on each lifetime of a scope. Add a little bit of salt to insult you need it to be atomic if you want it to run on SMP. This means for each time you have create/release the lifetime of an object you will make a lot of memory barriers, and create a lot of cache contention. But in practice the overhead is actually nought, and most of th…

[deleted]

Re: Apple is rewriting Foundation in Swift

#133

Post by Grustaf »

ksec wrote: post #77

Not a popular opinion. Current Apple and Swift felt somewhat like Apple and Dylan in the 90s. May be time could tell. A lot of people hate Objective-C, and was cheering for Swift in 2014. Now nearly a decade later, it seems time and resources could have been spent somewhere else.

What makes you say that? I don't think you can find many developers that would be willing to go back to Objective C.

Re: Apple is rewriting Foundation in Swift

#135

Post by deanCommie »

thrwawy74 wrote: post #42

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…

Who outside of Apple is using Objective C?

That's like...Apple's whole deal. Proprietary everything top-to-bottom.

Re: Apple is rewriting Foundation in Swift

#136

Post by GeekyBear »

dralley wrote: post #125
kevingadd wrote: post #65

Earlier quoted context omitted.

From what I've seen the ref counting can cause a big performance hit. Maybe this has improved in the last couple years?

Apple has always been preferential to reference counting (see Objective C) and it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it.

> it seems like they may have spent a fair bit of effort optimizing Apple Silicon for it

According to information released when the M1 came out: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.5 nanoseconds on an M1

Re: Apple is rewriting Foundation in Swift

#137

Post by rvz »

olliej wrote: post #129
iknowstuff wrote: post #116

Earlier quoted context omitted.

The who

Yet another chrome wrapper, but with VC funding.

And?

Brave (VC funded) is also a Chromium wrapper and Edge (Microsoft owned) is also one as well and both of the somehow managed to beat Firefox in usage. So what is you point?

Chrome and its derivatives is the reason why browsers like Firefox is failing to keep up and continues to lose users.

Using anything other than Chrome for a modern web browser is a losing battle. (Brave already tried that with Firefox and quickly switched to Chrome)

Re: Apple is rewriting Foundation in Swift

#138

Post by jb1991 »

thrwawy74 wrote: post #42

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…

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.

Re: Apple is rewriting Foundation in Swift

#139

Post by BulgarianIdiot »

plorkyeran wrote: post #91
w10-1 wrote: post #67

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

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.

Shame really. Apple's platform has so many good ideas I wanted Swift to bring to the world as a cross-platform open-source effort.

:(

Re: Apple is rewriting Foundation in Swift

#140

Post by GeekyBear »

aatd86 wrote: post #128
GeekyBear wrote: post #72

Earlier quoted context omitted.

> From what I've seen the ref counting can cause a big performance hit. Apple has been writing OS components in Swift for a while now. It certainly doesn't seem to be producing the performance issues we saw when Google attempted to write components for Fuchsia in Go or Microsoft's effort to create new features for Longhorn in .NET.

Was probably due to FFI for Go I'd assume. Do you have a reference somewhere I can read up?

It was discussed here when they decided their networking stack in Go would need to be rewritten for performance reasons, and banned the future use of Go for Fuchsia system components.

https://news.ycombinator.com/item?id=22409838

Post reply on HN