Hacker News new | ask | show | jobs
by djha-skin 1121 days ago
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
2 comments

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

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.
Modern, state-of-the-art, generational GC? Not being snarky, that’s literally the comparison.
There was never any way to implement a modern GC while keeping compatibility with Objective-C, which was the primary design goal of Swift.

Apple had a bad experience with GC in ObjC with libauto and learned their lesson that C and GC just don’t mix. You can never have a truly modern GC in C, because C cannot provide any of the guarantees that a GC needs to move objects around.

Using a modern GC entails sealing the language off in a bubble. Since Swift is mostly used to interface with system frameworks, you would end up paying a cost when interfacing with the system frameworks written in ObjC, making your modern GC useless most of the time.