4 ms·

I only have very little Rust experience, and would like to hear from a Rust veteran - as much as one can be - if that is considered good Rust, or if it's just a

by fredsir 10y ago

I only have very little Rust experience, and would like to hear from a Rust veteran - as much as one can be - if that is considered good Rust, or if it's just an example of how bad Rust can be if you don't know what you're doing, or are trying to showcase bad Rust. I would think it's the latter, but I don't know, to be honest.

iopq 10y ago
You could write <'a, T: Monoid + From<&'a str>> and omit the where clause, but that seems even less readable to me. The rest basically has to be there for the function to do what it does.
Manishearth 10y ago
It's basically an example of what happens when you try to use Haskell concepts in Rust; the type parameters explode quickly. Most rust functions are not like that. Some are. It's not exactly bad rust to have functions like that, but such functions should probably be uncommon in your codebase.
- iopq 10y ago
  Note that Monoid here is ONLY for the reason that Cow<str> doesn't satisfy Add. In fact, String doesn't satisfy it either. So I need to have a trait that allows me to call a function that concatenates my types. I already wrote how to concatenate Strings and Cow<str>s in my Monoid crate so I'm just re-using that. It could be T: Concatenable for all I care, but the rest of the function needs to look this way, more or less. I only have one type parameter, that's very common. I'm abstracting over String and Cow<str> because I want to bench the performance of both. (Cow<str> is always faster)
  - Manishearth 10y ago
    I'm not just talking about Monoid, I'm talking about the overall signature -- with the Fn and the abstractions it's very Haskelly. Such functions are not common in Rust. You find them (all the iterator adaptors, for one), and they can be "good Rust", but they're not common. Which is okay. (I don't disagree that Rust is more complicated than Python, just addressing GP's comment whether or not this is "good" rust.)
    - iopq 10y ago
      It's actually very common to pass around hashmaps of functions in dynamic languages. If anything, since you don't even have to know how they're implemented it's easier. I realize that my function incurs a run time cost because I'm making an array of trait objects. When I'm writing JavaScript I don't know and I don't care.
fiedzia 10y ago
Its non-trivial and it could be written simpler (the tuples part could get its own type alias, making it more readable and shorter), but its not particularly bad or good. You will find examples of this mostly in libraries, but rarely its something a beginner would write. You can actually do a lot without ever using lifetimes. Eventually you'll need to learn to read this though, and its just a matter of getting used to it. I'd say none of those is any harder to understand then let say nested list comprehension in python.

by fredsir 10y ago

iopq 10y ago

You could write <'a, T: Monoid + From<&'a str>> and omit the where clause, but that seems even less readable to me. The rest basically has to be there for the function to do what it does.

Manishearth 10y ago

It's basically an example of what happens when you try to use Haskell concepts in Rust; the type parameters explode quickly. Most rust functions are not like that. Some are. It's not exactly bad rust to have functions like that, but such functions should probably be uncommon in your codebase.

iopq 10y ago
Note that Monoid here is ONLY for the reason that Cow<str> doesn't satisfy Add. In fact, String doesn't satisfy it either. So I need to have a trait that allows me to call a function that concatenates my types. I already wrote how to concatenate Strings and Cow<str>s in my Monoid crate so I'm just re-using that. It could be T: Concatenable for all I care, but the rest of the function needs to look this way, more or less. I only have one type parameter, that's very common. I'm abstracting over String and Cow<str> because I want to bench the performance of both. (Cow<str> is always faster)
- Manishearth 10y ago
  I'm not just talking about Monoid, I'm talking about the overall signature -- with the Fn and the abstractions it's very Haskelly. Such functions are not common in Rust. You find them (all the iterator adaptors, for one), and they can be "good Rust", but they're not common. Which is okay. (I don't disagree that Rust is more complicated than Python, just addressing GP's comment whether or not this is "good" rust.)
  - iopq 10y ago
    It's actually very common to pass around hashmaps of functions in dynamic languages. If anything, since you don't even have to know how they're implemented it's easier. I realize that my function incurs a run time cost because I'm making an array of trait objects. When I'm writing JavaScript I don't know and I don't care.

fiedzia 10y ago

Its non-trivial and it could be written simpler (the tuples part could get its own type alias, making it more readable and shorter), but its not particularly bad or good. You will find examples of this mostly in libraries, but rarely its something a beginner would write. You can actually do a lot without ever using lifetimes. Eventually you'll need to learn to read this though, and its just a matter of getting used to it. I'd say none of those is any harder to understand then let say nested list comprehension in python.