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

171–180 of 263 posts

Re: Apple is rewriting Foundation in Swift

#171

Post by scns »

_the_inflator wrote: post #160
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…

You got a point. On the other side, arguably, one could say the same about C#, JavaScript or Python. It took real effort from Microsoft into the Open Source space to make it more widely popular. Far away from Java or JavaScript, but I see many similarities between the development and evolution of Swift and C#. Almost everything starts as a domain specific language. Same goes for JavaScript. First browser only, then t…

Python came preinstalled on pretty much every Linux box before Jupyter IIRC.

Re: Apple is rewriting Foundation in Swift

#172

Post by scns »

delta_p_delta_x wrote: post #97
w10-1 wrote: post #71

Earlier quoted context omitted.

The Swift compiler and standard library are pretty tightly linked. The Swift type system is getting pretty complicated already, handling a whole range of lifetimes, async, the combination of protocols, generics, existentials, etc. with some magic handling for arrays and maps in the library. So the cost of cross-platform effort would be significant. The greatest barrier to entry is XCode. It's archaic, impossible to e…

.NET MAUI[1] and AvaloniaUI[2] run on iOS pretty well, and one can use Rider/VS Code/other editors to develop apps. [1]: https://learn.microsoft.com/en-us/dotnet/maui/ios/cli [2]: https://docs.avaloniaui.net/tutorials/developing-for-mobile/...

Hope this keeps getting investment and support by Microsoft. Choice and competition are very welcome, even though i code neither iPhone Apps nor C# ATM.

Re: Apple is rewriting Foundation in Swift

#173

Post by scns »

worrycue wrote: post #118
MattRix wrote: post #96

Earlier quoted context omitted.

Apple’s problem has never been the “barrier to entry”. They know developers will make apps for their platform no matter what. If Swift becomes more universal it makes it easier for Apple developers to also develop for Android (etc) which Apple would see as a bad thing.

Wouldn't developers also develop for Android no matter what?

Some Apps are exlusive to iOs and some start out there, because that is where the money is.

Re: Apple is rewriting Foundation in Swift

#175

Post by scns »

pkulak wrote: post #158
cellularmitosis wrote: post #124

Earlier quoted context omitted.

> without a big performance hit. You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect. Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.

Ref-counting GC is pretty slow. It’s great for avoiding stop-the-world pauses, which can be really important for UI stuff like what Swift is used for, but you won’t win any throughput awards.

So well engineered for its use case. Was Go optimized for throughput?

Re: Apple is rewriting Foundation in Swift

#176

Post by Someone »

olliej wrote: post #127
stevefan1999 wrote: post #120

Earlier quoted context omitted.

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…

Swift's refcounting is atomic (as is objc's). As long as you're not under contention most benchmarks I've seen show negligible overhead (from the addition of atomicity, the refcount overhead is still there) for uncontended access. But IME if you do have many threads walking the same data structure you end up spending stupid amounts of time fighting the refcounting. This applies even if the data structure is immutable…

> Swift's refcounting is atomic (as is objc's)

Most of the time it’s possible to avoid atomic instructions and still be thread-safe. https://dl.acm.org/doi/10.1145/3243176.3243195:

“BRC is based on the observation that most objects are only accessed by a single thread, which allows most RC operations to be performed non-atomically. BRC leverages this by biasing each object towards a specific thread, and keeping two counters for each object --- one updated by the owner thread and another updated by the other threads. This allows the owner thread to perform RC operations non-atomically, while the other threads update the second counter atomically. We implement BRC in the Swift programming language runtime, and evaluate it with client and server programs. We find that BRC makes each RC operation more than twice faster in the common case. As a result, BRC reduces the average execution time of client programs by 22.5%, and boosts the average throughput of server programs by 7.3%.”

I remember reading that this made it into Swift, but cannot find it, so I’m not sure anymore.

And of course, the Swift compiler tries to avoid unnecessary refcount updates.

Re: Apple is rewriting Foundation in Swift

#177

Post by scns »

iknowstuff wrote: post #116
rvz wrote: post #111

Earlier quoted context omitted.

> No one outside Apple chooses Shift unless they want to build something in Apple's ecosystem. “No one” Yet The Browser Company (The one that is hyping the Arc Browser) is writing their browser in Swift to support Windows. [0] which that is their main product. The Browser Company is not “No one”. [0] https://m.youtube.com/watch?v=Xa_fNuaSE_I EDIT: So this video doesn't show someone choosing Swift outside of Apple and…

The who

The band?

Sorry for the joke, know it is frowned upon, did it anyway.

Re: Apple is rewriting Foundation in Swift

#178

Post by realusername »

pilif wrote: post #60
lyu07282 wrote: post #56

Earlier quoted context omitted.

If they just had a proper cross platform standard library and package manager it might be more successful, it is a pretty cool language. But the north Korean esque closed apple ecosystem makes that impossible, all of that is intentional.

The package manager has been open source, cross platform and available since pretty much from the start. The standard library is becoming cross-platform as we discuss it here.

> The standard library is becoming cross-platform as we discuss it here.

I'd argue that it's too late already, the ship has sailed, Swift is heading the same way as C#.

Re: Apple is rewriting Foundation in Swift

#179

Post by stephen_g »

stephen_g wrote: post #52
KerrAvon wrote: post #23

Earlier quoted context omitted.

This will not directly affect AVFoundation, or any other framework which is not Foundation itself.

Not as part of the work from this announcement, no, but it is surely an indication that Apple is moving in a direction where those other libraries will eventually be re-written in Swift too.

(Oops, I commented before looking at the link and thought it was pointing at something like this - https://www.swift.org/blog/future-of-foundation/ - not the git repository! But you know what I mean)

Re: Apple is rewriting Foundation in Swift

#180

Post by retendo »

cellularmitosis wrote: post #124
GeekyBear wrote: post #63

Earlier quoted context omitted.

> just... completely don't understand the appeal of Swift beyond it being Apple's in-house language. It's like Rust in that it offers memory safety by default without a big performance hit.

> without a big performance hit. You might be surprised (I was). Most of the benchmarks I’ve seen place it more in the neighborhood of golang and v8, rather than the C, C++, rust neighborhood you might expect. Another commenter in this thread highlighted that the ref-counting GC is what keeps it out of the C / Rust performance neighborhood.

Swift doesn't have a GC. The automatic reference counting is a feature that just inserts retain/release statements at compile time, so there is no additional process that handles that. I would suspect that the performance hits originate from other things.
Post reply on HN