Hacker News Reader

Comment by zesterer | Hacker News Reader

Code 'bloat' is a bizarre metric to use for anything unless you're on a platform with incredibly constrained executable memory like an embedded device.

The fact that Rust specialises its generic code according to the type it's used with it not some inherent disadvantage of generics. That's what they're supposed to do. By choosing to not specialise, you're actively making the decision to make your code slower. Rust has mechanisms for avoiding generic specialisation. They're called trait objects and they work brilliantly.

When you use void* in your data structures in C, you're not winning anything when compared to Rust. You're just producing slower code that mimics the behaviour of Rust's trait objects, but more dangerously.

Code 'bloat' (otherwise known as 'specialising your code correctly to make it run faster') is not a reason to not use Rust in 2021, so please stop pretending that it is.

View on HN

It's not that simple. While fully specializing everything wins microbenchmarks, as C++ has shown time and time again, it can easily lose performance in large applications. If fully specializing code saves a few branches in the hot loop, but also blows through all the L1i, it can easily be a huge net negative.

> Rust has mechanisms for avoiding generic specialisation. They're called trait objects and they work brilliantly.

As someone who uses a lot of rust, they are sort of the red-headed stepchild. As a minimum to make the properly usable, we need a way of passing one object with multiple different traits.

> As a minimum to make the properly usable, we need a way of passing one object with multiple different traits.

Supertraits?

That is possible, but gets really hairy if you use a lot of trait objects.

> As someone who uses a lot of rust, they are sort of the red-headed stepchild. As a minimum to make the properly usable, we need a way of passing one object with multiple different traits.

What do you mean?

    fn foo<T: TraitA + TraitB>(x: T) { T.something(); }

Unless TraitB is an auto trait, that isn't currently valid?

From the reference:

> Trait objects are written as the optional keyword dyn followed by a set of trait bounds, but with the following restrictions on the trait bounds. All traits except the first trait must be auto traits, there may not be more than one lifetime, and opt-out bounds (e.g. ?Sized) are not allowed.

The only one of those restrictions that is acceptable to have is the single lifetime one. All the others are seriously restricting. The devs seem to agree, but work on this aspect of rust is very slow, and people are arguing on how to implement it. (I, for one, feel very strongly that dyn TraitA + TraitB should have a size of 3 pointers. That is, no magic combining vtables, just every added trait adds a new pointer to vtable.)

This is not a trait object, and so that part of the reference is irrelevant.

Here's that example working: https://play.rust-lang.org/?version=stable&mode=debug&editio...

I am not entirely sure that it answers your point though; what you want is trait A or trait B, not both, right?

Ah sorry, no, what I want is specifically a trait object that satisfies both trait A and B.

Yes, in that case you are 100% right, your parent didn't provide an actual solution.

I didn't understand what you meant by a trait object, mea culpa.

Reply on news.ycombinator.com