Hacker News Reader

Comment by spotman | Hacker News Reader

Can you elaborate on the cognitive overhead vs a GC language like golang or java? (With regards to memory)

To me sure there is things you think about but generally memory performance is less of a mental burden.

Also, swift 4 is supposed to support a rust like memory model. Not sure if it's opt in or how it will work but my impression is that it's memory model is about to support some new use cases to make it appropriate for more memory critical tasks.

View on HN

Speaking only for myself, avoiding or breaking retain cycles is a noticeable problem in Swift code that simply isn't there in languages with a proper garbage collector. Among newer iOS programmers, it's a big point of confusion to figure out when a callback closure should use [weak self] versus capturing self strongly, for example. I've seen a lot of people struggle to understand, completely fail, and end up dogmatically using [weak self] everywhere whether it's needed or not (and sometimes where it's actually harmful).

With @nonescaping becoming the default, this might become a bit simpler. Not too much, but a bit.

It is much easier than in either C++ or Rust.

Technically true, but very misleading in Rust's case. In Rust you rarely have to break retain cycles in the first place, simply because you don't use reference counting much. Things like "weak self" are not a problem, because closures aren't reference counted unless you explicitly make them so (and in fact I don't think I've ever seen a reference counted closure in practice).

I agree.

I only mentioned Rust, because of ergonomics, since the compiler cannot guide the user unless the types are known.

Or is already something in place to make use of intrisics for better error messages in such cases, instead of just giving a type error?

Don't C++ and Rust offer the same facilities? C++ has std::weak_ptr and Rust has std::rc::Weak.

Yes, but they are library calls without any help from the compiler.

How does that make them any more difficult to use?

The compiler can provide better error messages and guide the user, whereas with library types, at least on C++'s case it requires help from external tooling.

With Rust, while you can make use of the type system, it is harder for the compiler to provide such guidance, unless the types are somehow blessed.

What sort of guidance does Swift provide here? And nothing prevents Rust or C++ compilers from becoming aware of these types and providing specialized diagnostics for them.

I said it can, not that it does it already.

My Swift experience is constrained to the GNU/Linux version, so I don't know if XCode is already doing something in this direction.

Sure one can have blessed library types that the compiler knows about, but then from language design point of view it creates a decision between those types and others written by developers, but with similar semantics.

Since you said it's easier than these other languages, I thought you were referring to how the languages work now.

There's nothing wrong with special treatment for stuff in the standard library. C and C++ already do this with many things (e.g. many compilers understand calls like memcpy and will emit optimized code based on the standard library semantics) and Swift gives special treatment to built-in types like Optional.

The distinction here is fairly blurred. The Swift implementation of weak pointers is mostly in the runtime library already, it's just that the compiler hides it a bit so you don't write the names of the calls directly.

Sure, I was more thinking about the language geek point of view.

Thanks for clarifying.

Understood. If you have any ideas for cool diagnostics or other guides, I'd be interested in hearing. I couldn't think of anything offhand, but that's probably just my lack of imagination. I would love to see some static analysis help for finding retain cycles and recommending how to break them, but I'm not sure if that's practical.

You have to manually optimize away unnecessary reference counting without help from the compiler.

I have never seen unnecessary reference counting be a problem in Rust. That's because not manipulating the reference count requires an explicit action—.clone()—and borrowing is so expressive that you rarely need to manipulate the counts.

I guess that's because in Rust you never need defensive reference counting thanks to the borrow checker.

Rust's borrow checker actually helps with this a lot- you can hand out references to the Rc-ed data without modifying the count, and the compiler will enforce that the count is not decremented until the references are dead. Combined with the fact that plain references are more idiomatic than Rc/Arc, this leads to pretty similar results.

That is true, but a totally different issue from breaking or avoiding retain cycles.

Reference counting has upsides and downsides. If you look at the lengths that some Java based projects like Spark have to go to in order tame the GC, then you have to question whether tracing GC is the right choice in the age of hundereds of GBs of memory.

On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. Swift's own collection interface changed massively between 2.x and 3 and I believe the main reason for the redesign was that the old design required too much reference counting. (I'm not completely sure this is an accurate reflection of their thinking though)

> On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden.

This is very wrong on both points. Reference counting has a lot less mental burden compared to GC, because it's predictable. You can rely on destructors to actually work and be useful. For example, you don't have to keep track of whether you closed your file descriptor or not, but in GCd languages you have to do that manually, sometimes even with the same reference counting, but hand-written and explicit. Reference counting is also very fast, with the exception of concurrent decades old implementations, that are irrelevant today.

I don't disagree on the benefits of RAII at all. I love it. It's a much cleaner and more general resource management idea than a tracing GC.

But incrementing/decrementing an atomic value in a tight loop apparently creates a performance problem that is severe enough for the Swift team to redesign their API. That wasn't decades ago:

"Code that handles indices has to perform atomic reference counting, which has significant overhead and can prevent the optimizer from making other improvements."

https://github.com/apple/swift-evolution/blob/master/proposa...

Reply on news.ycombinator.com