4 ms·
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 fac
by zesterer 6y ago
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.
- Tuna-Fish 6y agoIt'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.
- zesterer 6y ago> As a minimum to make the properly usable, we need a way of passing one object with multiple different traits. Supertraits?
- Tuna-Fish 6y agoThat is possible, but gets really hairy if you use a lot of trait objects.
- loeg 6y ago> 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(); }
- Tuna-Fish 6y agoUnless 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.)
- steveklabnik 6y agoThis 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&edition=2018&gist=745c3742eefd594ca988f77d87c540cd 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?
- Tuna-Fish 6y agoAh sorry, no, what I want is specifically a trait object that satisfies both trait A and B.
- steveklabnik 6y agoYes, in that case you are 100% right, your parent didn't provide an actual solution.