Hacker News Reader

Comment by sevensor | Hacker News Reader

So, if you're writing in Rust, why not box everything, most of the time? Pay the cost of dereferencing to make it easier to reason about closures? Save unboxed values for situations where they're either trivial to reason about or you're sure there's a performance problem? Is this regarded as bad form?

(I don't really know Rust, but I'm watching with interest. As my comment may suggest, I'm more familiar with C and Python.)

View on HN

I think the general philosophy of Rust is that programmers should think about the data ownership semantics of their programs. Rather than boxing everything to make it easier to reason about closures, one should strive to write programs that use closures in a way that is easy to reason about.

Unboxed closures aren't any harder to reason about than boxed closures, and any function that accepts an unboxed closure accepts a boxed closure, too, which is why library authors should almost always prefer accepting unboxed closures (as withoutboats said in another comment.)

You can. I'm not sure how much it's done or isn't done, really. Pre-1.0 Rust even had mandatory boxed closures, and until fairly recently (1.26?) you still had to box them in more situations than you do today.

Because, contrary to what the OP is saying, writing normal Rust is actually easy and straightforward. So you don't have to "box everything" by default. You only need that when you do some asynchronous work via generic interfaces.

If you intend to box everything most of the time, you might as well just use a higher-level language with GC, like C# or Swift.

Reply on news.ycombinator.com