[afavour]

It’s not really a question of fairness. The existing codebase is C++, the new stuff is Swift. Hence the comparison.

I’ve written both Rust and Swift while being an expert in neither. I wouldn’t say Swift has no pluses in comparison, reference counting is often a lot easier to reckon with than lifetimes, for one. I’m actually curious what a large multithreaded Swift codebase looks like with recent concurrency improvements. Rust’s async story isn’t actually that great.

[worik]

> Rust’s async story isn’t actually that great

I agree. People's perspectives differ. It abhor `async/await` in Rust. It has poisoned the well IMO for asynchronous Rust programming. (I adore asynchronous programming - I do not need to pretend my code is synchronous)

But that is taste, not a comment on poor engineering!

The lack of the borrow checker in Swift is what makes it approachable for newcomers, as opposed to Rust which is a harsh mistress.

But reference counting is such a silly idea. Swift really should have a garbage collector with a mechanism or subset to do that very small part of programming that cannot be done with a garbage collector. That would have been design!

I fear that Swift is going to get a borrow checker bolted on - and have the worst of both worlds....

[consteval]

Reference counted objects have deterministic lifetimes, like Rust or C++. Garbage collected languages don't have that. Essentially a reference counter automates some* of the ideas of the borrow checker, with a runtime cost as opposed to a compile time one.

The great thing about automatic reference counting is you can elide the incrementing and decrementing a lot of the time. Stronger guarantees, such as saying "this object is single-threaded" lead to even more optimizations.

[ec109685]

I don’t think Apple would want to sacrifice the determinism that refcounting provides for garbage collection. iOS apps are still more buttery smooth than Android in many cases.