Live data from Hacker News

Apple is rewriting Foundation in Swift

github.com

141–150 of 263 posts

Re: Apple is rewriting Foundation in Swift

#141

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…

The same appeal as .NET on the Windows ecosytem, Objective-C on NeXT/OS X, Java/Kotlin on Android (plenty of stuff that is Android only beyond the basic standard library, C++ OS specific SDKs,....

Many people are more than happy to do all their career on a specific platform.

Re: Apple is rewriting Foundation in Swift

#142
post #79

Earlier quoted context omitted.

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.

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.

Because Google and JetBrains are in bed together in what concerns Android development tooling.

Try to use Kotlin without the Android ecosystem, it is just syntax sugar for the JVM.

Re: Apple is rewriting Foundation in Swift

#143
post #127

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…

IME Swift’s refcounting is either incredibly inconsequential or a dealbreaker, with very little in between. They’ve done a very good job of optimizing it to the point where it’s barely measurable even in perf sensitive code… until you hit the scenarios where it completely murders performance and there’s nothing you can do about it.

Hopefully the upcoming ownership functional will help in those cases.

Re: Apple is rewriting Foundation in Swift

#144

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.

With various levels of implementation quality, Kotlin/Native had to be rebooted, on JS it hardly offers anything better than TypeScript, on the JVM it is mostly used by Android shops anyway.

Re: Apple is rewriting Foundation in Swift

#145

Long overdue -- there's a very noticeable difference in runtime errors with Swift libraries vs the rest. This is especially true of AVFoundation, which is an absolute mess of hidden and undocumented state. Swift optionals and enums will go a long way to fixing that.

One of the interesting side effects of this is that those new libraries are going to have significantly worse introspection and hotpatching opportunities, so they better code them correctly, or things are going to really suck.

Re: Apple is rewriting Foundation in Swift

#146

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…

There's not even anything technically interesting about the language. Reference counting? Really? We have so much more than that and you just went with reference counting. Ugh

> There's not even anything technically interesting about the language

It's a modern statically compiled language with complex generics, that supports providing a generic interfaces in libraries with retaining ABI compatibility. Which no other modern "system" language supports. That's fairly technically interesting to me.

> We have so much more than that and you just went with reference counting

Like what?

The options for memory safe shared ownership are refcounting or GC.

Assuming you're talking about rust, that's just C++: object lifetime is lexical, and if you need it to last longer you have to use Arc/Rc/shared_ptr. The purpose of the lifetime and borrow checkers is to ensure exclusive access, and reduce the copy/destruction churn that you get from the C++ model (a hypothetical C++ that only allows the use of unique_ptr instead of raw pointers - obviously C++'s type system and approach to memory safety is not a Good Thing).

But it's important to realize rust did not create a new solution to object lifetime management for shared objects.

It's also important to realize that rust was designed in an environment where there was no existing code to interoperate with, whereas Swift was designed to work with the existing Darwin APIs and objective-c which are all refcounted. So even if no refcounting was the goal you'd end up with a new language, designed for a specific environment, and the default behaviour would not be correct.

Now that the language is more established, and it's less critical for every part of the language to have objc interop they are working on pure ownership semantics, for the same reason as rust: it saves copies without requiring a refcount[1]

[1] https://github.com/apple/swift/blob/main/docs/OwnershipManif...

Re: Apple is rewriting Foundation in Swift

#147
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 a new effort that is committed to shipping on Apple platforms. It will also be the first time 3rd parties can get code changes into Foundation.

What, sending patches in feedback assistant and then getting an engineer to merge them in wasn’t it?

Re: Apple is rewriting Foundation in Swift

#148

Earlier quoted context omitted.

There's not even anything technically interesting about the language. Reference counting? Really? We have so much more than that and you just went with reference counting. Ugh

What would you use instead of ref counting? Swift is an embedded language for Apple’s own chips, they can optimize the hell out of refcounting at silicon level.

There really is only so much you can do - especially once you've got refcount churn on objects being used across multiple threads. Swift's refcounting can get truly annoying at times.

Re: Apple is rewriting Foundation in Swift

#149

Earlier quoted context omitted.

I don’t know much about Rust, but Swift can prevent data races at compile time by using the Actor type.

It could catch them before that using ownership, at the cost of lower performance. Though Swift concurrency is mostly about "concurrency" not "parallelism", which is the one that has data races.

Ownership hasn’t shipped yet.

Re: Apple is rewriting Foundation in Swift

#150

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…

[dead]
Post reply on HN