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

91–100 of 263 posts

Re: Apple is rewriting Foundation in Swift

#91

Post by plorkyeran »

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.

Re: Apple is rewriting Foundation in Swift

#92

Post by comex »

GeekyBear wrote: post #72
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?

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

But it's mostly replacing Objective-C code which was already not particularly fast – as opposed to the C++ or C code used more often in performance- or memory-sensitive areas.

My experience with Swift is somewhat limited, because every time I've tried to use it, I've run into glaring performance issues and had to switch language. It might be reasonably performant compared to Go or .NET, but it's nothing like Rust.

Re: Apple is rewriting Foundation in Swift

#93

Post by plorkyeran »

LispSporks22 wrote: post #76

Will it still all call send_msg and friends? Like can I still call into Foundation via C FFI or Objective C?

Yes. This is intended to be a reimplementation of Foundation with the same API, including being usable from obj-c. They've added a few compiler features recently to cover the gaps where there were some kinds of obj-c types that couldn't be defined from Swift.

Re: Apple is rewriting Foundation in Swift

#94

Post by noisy_boy »

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

I think many also find its syntax more approachable compared to that of Rust. It's got a lot of bells and whistles, but newcomers don't have to use them right away and can pick up more advanced bits as they become comfortable with doing so.

I did the Swift tutorial a short while ago and it was a breeze. I found it more approachable than Rust (I do like Rust).

Re: Apple is rewriting Foundation in Swift

#95

Post by karismatic »

Swift has been a hugely successfully language.

Mostly at slowing down iOS runtime performance per clock cycle, and increasing compilation times.

Its also been hugely successful at punishing companies for using it, since it didnt really work for a few versions.

While there have been fewer crashes (sort of) due to the switch, as someone who worked for years in Objective C and years in Swift, I honestly never felt that Swift significantly improved much except allocation rituals and properties.

I do however enjoy Kotlin for the backend because it has some nicer semantics for object construction.

While I do admire the work that Apple has put into Swift, I really felt that Apple was trying to "impress everyone", with a whole lot of bikeshedding and sick amoutns of code generation to convince us it was the right thing to do.

Frankly, apps run over 10 times faster in obj C and xcode with Swift is probably my least favorite and sort of non-ergonomic experience close to DOS batch file dev in Windows Notepad.

Re: Apple is rewriting Foundation in Swift

#96

Post by MattRix »

nequo wrote: post #61
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.

Why is it not better for Apple to make Swift truly cross-platform? Is it just that the maintenance cost is not worth it? Or would it threaten its ecosystem in a way that I don't understand? It would seem that making Swift cross-platform would make Apple's ecosystem more accessible to developers. The barrier to entry would be lower if developers only needed to learn the APIs and not a whole new language and its toolin…

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.

Re: Apple is rewriting Foundation in Swift

#97

Post by delta_p_delta_x »

w10-1 wrote: post #71
nequo wrote: post #61

Earlier quoted context omitted.

Why is it not better for Apple to make Swift truly cross-platform? Is it just that the maintenance cost is not worth it? Or would it threaten its ecosystem in a way that I don't understand? It would seem that making Swift cross-platform would make Apple's ecosystem more accessible to developers. The barrier to entry would be lower if developers only needed to learn the APIs and not a whole new language and its toolin…

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

Re: Apple is rewriting Foundation in Swift

#98

Post by masklinn »

baby wrote: post #75
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…

If they had waited a little bit Rust would have been a great option. That's a shame.

Unlikely, rust is rather inconvenient for gui applications.

And not at all compatible or easily bridgeable with obj-c, which was not optional.

Re: Apple is rewriting Foundation in Swift

#99

Post by d3nj4l »

fnord77 wrote: post #87
philwelch wrote: post #81

Earlier quoted context omitted.

I thought Kotlin was pretty widely used as a Java alternative on the backend

Kotlin seems kinds of pointless with the features in newer Java versions

No amount of lipstick on the java pig will make it as ergonomic to use by default as kotlin.

Re: Apple is rewriting Foundation in Swift

#100

Post by aw1621107 »

wudangmonk wrote: post #45
KerrAvon wrote: post #25

Earlier quoted context omitted.

They both compile slowly because they have similarly complicated type systems. What do you use in Rust that Swift doesn’t yet provide?

You can have a good type system and have fast compile times. In every single language with 'complicated type systems' it always comes down to type inference on polymorphic types which causes these issues, this has been known for over 40 years yet the same issue seems to be rediscovered again and again like it was something new. I sure hope the author learned the right lesson from the failure that is Swift and Mojo tu…

> it always comes down to type inference on polymorphic types which causes these issues

Unless I'm thinking of something different, doesn't OCaml have type inference on polymorphic types and fast(ish?) compile times?

I was under the impression that the breakdown of causes for Rust projects compiling slowly is very project-dependent as well. From what I can remember common culprits were monomorphization and/or LLVM, though I'm not sure if that has changed recently.

Post reply on HN