Live data from Hacker News

Apple is rewriting Foundation in Swift

github.com

111–120 of 263 posts

Re: Apple is rewriting Foundation in Swift

#111

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…

> 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 using on a different platform (Windows) and doesn't disprove the claim of "No one outside Apple chooses Swift"?

Surely you can do better than some of the very low effort replies below.

Re: Apple is rewriting Foundation in Swift

#112

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…

My experience was the opposite, I really like Swift but its usefulness is held back by the lack of a wider community. I'm not sure if that's due to a lack of investment on Apple's part, or maybe that it lives in an unhappy compromise between C++ and Python where there's always a more mature alternative that's good enough, but the language itself is quite nice to write.

Same, I find swift so much more ergonomic and beautiful than rust, but the development story outside (and inside) of xcode is just ugly

Re: Apple is rewriting Foundation in Swift

#113

Hot-take from someone who is currently helping to port GNUStep's implementation of the Foundation framework to the Sega Dreamcast: Gross. The whole appeal of Foundation was having this incredibly convenient, beautiful, high-level object-oriented API ontop of low-level, statically compiled performant C... The true path forward for computing is clearly an alliance among the holy trinity of god's C languages: C, C++, an…

Foundation has not been a pure layer on top of CoreFoundation for over a decade. Some class implementations are unified on the ObjC version, not the pure C CoreFoundation version.

Objective-C got good enough that all processes on Apple platforms have the objc runtime in their address space whether they want it or not and many pure C or CF-like frameworks are built on ObjC under the covers.

Re: Apple is rewriting Foundation in Swift

#114
post #79

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…

Totally valid point that swift is only useful for developing for Apple products, but this same criticism also applies more or less to Kotlin on Android. If you are dealing with iOS it is a joy compared to objective C. I would also add that it is a really nice language in general that is modern, expressive and general ergonomic.

At least I got to integrate Spring Boot well with Kotlin. Same goes for writing Minecraft mods.

Re: Apple is rewriting Foundation in Swift

#115

Earlier quoted context omitted.

Kotlin wasn't developed for Android. And can be run anywhere. It was JetBrains pet project to fix archaic stuff in Java without making a Scala. It was designed from the get go for a wide base (as wide as java). I'm not sure how it became Android's main target, but I doubt it was the original purpose.

Further to that point, Kotlin mainly targets the JVM (which can run pretty much everywhere), but also can be compiled to JavaScript, LLVM, and a bunch of other targets. Honestly the only times I've evaluated Kotlin for personal projects was bc of that flexibility.

recently kotlin can even be used to compile to native and wasm, but gradle makes it almost less usable than swift

Re: Apple is rewriting Foundation in Swift

#116
post #111

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…

> 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

Re: Apple is rewriting Foundation in Swift

#117
The performance "optimizations" are all about eliminating the bridge between ObjC and Swift.

I'd love to see a comparison of how the functions work within their own realm, e.g.:

- Speed of a date function in pure ObjC, tested in ObjC realm with no Swift bridge

- Speed of the same date function in pure Swift, tested in Swift realm with no ObjC bridge.

Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline.

Re: Apple is rewriting Foundation in Swift

#118
post #96
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…

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?

Re: Apple is rewriting Foundation in Swift

#119
post #87

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

Would Java had advanced without Kotlin on its doorstep?

Re: Apple is rewriting Foundation in Swift

#120

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.

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 the time you rather deal with I/O bound problem more than an additional atomic increment operation. Modern processor is fast enough to deal with them in few cycles in around the order of 10 nanoseconds

Post reply on HN