Hacker News Reader

Comment by pcwalton | Hacker News Reader

Swift is GC'd and has a large runtime. (Reference counting is a form of garbage collection.) Rust is manually memory managed and effectively has no runtime.

The languages are very different.

View on HN

Swift uses reference counting for reference types, but emphasizes value types. Rust supports reference counting for certain types, but emphasizes value types too.

Also observe that Rust's drop flag is a form of (1-bit) reference counting.

In this particular area, they are more similar than different.

Rust's drop flag is quite different because it's local. Most pointers are not reference counted in Rust, whereas they are in Swift.

Similar perhaps, but not that similar.

Which pointers? Here's all the different pointers I know of in Rust, and their equivalents in Swift:

Rc/Arc <-> class types

Raw pointers <-> UnsafePointer/UnsafeMutablePointer

References <-> inouts

Trait objects <-> Protocol objects

Box <-> indirect enum (arguably)

Did I miss any?

Of the core language features, protocol objects are the only case where Swift uses reference counting and Rust does not.

Swift doesn't have the borrow checker, which means that in order to ensure safety the expressiveness is really limited unless you use RC. That's why essentially all Swift code uses RC, and Rust code rarely does.

There's a big difference between technically having manual memory management and having it actually widely used and practical.

Yes, RC is the primary way to safely manage lifetimes of reference types in Swift. You can drop down to unsafe constructs to avoid RC overhead, and I sometimes do that in hot loops.

Using unsafe to improve performance is not unfamiliar in Rust either, though Rust gives you better tools for building safe abstractions around it.

Shared ownership is routine in UI programming - think event handlers, etc. These are the apps most commonly written in Swift. Does Rust avoid needing shared ownership for these types of apps? If so, how?

Rust's drop flag is totally unlike Swift's atomic heap reference counting. The drop flag is just an implementation detail that procedures sometimes use to determine whether to run the destructor. It is usually optimized away. It is quite feasible to program without drop flags if you really don't want them, though they never show up in profiles (unlike swift_retain). We could statically eliminate drop flags if we wanted to, via tail duplication. (But we don't, because the drop flags have effectively zero runtime overhead, unlike RC.)

"Rust is manually memory managed"

Is it? As I understand it, memory is handled primarily by the ownership system, and sometimes by reference counting. That doesn't seem to be manual memory management to me.

It is basically implicit manual memory management. You make sure that your ownership is properly accounted for and it will then properly manage the memory they use. Unlike in GC languages, you pretty much have to understand everything about how your resources are managed, even in the API design phase.

Is reference counting not implicit manual memory management as well?

No! Reference counting is dynamic tracking of object lifetimes. If reference counting is implicit manual memory management, then so is tracing GC!

Manual means "a thing operated or done by hand rather than automatically or electronically, in particular." It is very strange to me that you've decided the manual means: non-dynamic tracking of object lifetimes.

Garbage collector frees objects when there are no more references to them. It thus does automatic memory management.

Borrow checker on the other hand doesn't alter lifetimes of objects, instead it doesn't allow you to keep references to things that were destroyed. I.e. it doesn't manage memory.

Sure, but I was talking about Rust's ownership system which certainly does alter the lifetime of objects. Rust automatically frees objects when the owner scope ends.

Reply on news.ycombinator.com