4 ms·

> I don't consider Rust to be a particularly complex language > I put it on par with Python Python doesn't have complicated lifetime errors, confusing trait no

by iopq 10y ago

> I don't consider Rust to be a particularly complex language > I put it on par with Python Python doesn't have complicated lifetime errors, confusing trait not being satisfied errors. Python function declarations don't need three lines of code. I mean wtf is this? fn accumulate<'a, T: Monoid>(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> Option<T> where T: From<&'a str> there's about ten language features in these lines of code that Python doesn't have

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.
pcwalton 10y ago
I don't agree with kibwen about Rust being just as simple as Python, but I also think it's a bit of a pointless comparison, given that Python is dynamically typed and Rust is statically typed. Any type system feature is something that Python trivially doesn't have.
kibwen 10y ago
I consider "complexity" to refer to both the quantity of language features and the number of significant or surprising interactions that exist between every language feature. Rust and Python are both medium-complexity languages, but the difference is that in Python you can totally ignore e.g. generators or decorators or (oh god) metaclasses and still get work done. In Rust you really can't get work done until you understand references and move semantics. The total height of each learning curve is the same, but Rust's is more like a cliff than a gentle slope, which is why it's crucial that we put so much focus on documentation.
- iopq 10y ago
  I ran into higher rank lifetimes while trying to use a library in my program. You can totally pass closures around in a dynamic language like JavaScript without any issues (you just pay for it in performance). In Rust `-> impl Trait` is a new feature so it's still not at all polished. I would argue that Rust has a higher learning curve overall than any dynamic language because of its type system.

by iopq 10y ago

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.

pcwalton 10y ago

I don't agree with kibwen about Rust being just as simple as Python, but I also think it's a bit of a pointless comparison, given that Python is dynamically typed and Rust is statically typed. Any type system feature is something that Python trivially doesn't have.

kibwen 10y ago

I consider "complexity" to refer to both the quantity of language features and the number of significant or surprising interactions that exist between every language feature. Rust and Python are both medium-complexity languages, but the difference is that in Python you can totally ignore e.g. generators or decorators or (oh god) metaclasses and still get work done. In Rust you really can't get work done until you understand references and move semantics. The total height of each learning curve is the same, but Rust's is more like a cliff than a gentle slope, which is why it's crucial that we put so much focus on documentation.

iopq 10y ago
I ran into higher rank lifetimes while trying to use a library in my program. You can totally pass closures around in a dynamic language like JavaScript without any issues (you just pay for it in performance). In Rust `-> impl Trait` is a new feature so it's still not at all polished. I would argue that Rust has a higher learning curve overall than any dynamic language because of its type system.