3 ms·

Generics, not templates. They're not opaque. Templates are more opaque because of the lack of self documenting bounds, perhaps (i still wouldn't call them opaq

Generics, not templates. They're not opaque. Templates are more opaque because of the lack of self documenting bounds, perhaps (i still wouldn't call them opaque, just more so than Rust generics) This is the millionth time you're repeating that garbage about imperative control flow. It boils down to a use of closures in a few stdlib functions. We've had this argument before, the essence of your point is that it is different from C. Of course there is a learning curve but that is there the other way too. Once you get used to it the control flow is pretty straightforward. And in most cases you can avoid the closures and write your if or loop manually.

Animats 10y ago
Rust's control flow primitives are coming to be defined by libraries, not the language, and tend to grow over time. For a long time, we've been able to get by with a small, well-understood set of control flow primitives, those defined by Wirth many years ago. Now we have this in Rust: Type Option. The 2014 version.[1] The 2016 version.[2] (Coming soon, the "?" operator.[3]) Here's an example of excessive cleverness [4]: fn main () { let number: f64 = 20.; // Perform a pipeline of options. let result = Some(number) .map(inverse) .map(double) .map(inverse) .and_then(log) .map(square) .and_then(sqrt); // Extract the result. match result { Some(x) => println!("Result was {}.", x), None => println!("This failed.") } } (It's surprising that you can use .map on a singleton. Does this actually generate collections of one element and discard them, or what?) The designers of Go knew when to stop. The designers of Rust don't. [1] https://web.archive.org/web/20140814230239/http://doc.rust-lang.org/std/option/type.Option.html https://web.archive.org/web/20140814230239/http://doc.rust-l... [2] https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html [3] https://github.com/rust-lang/rust/issues/31436 https://github.com/rust-lang/rust/issues/31436 [4] https://hoverbear.org/2014/08/12/option-monads-in-rust/ https://hoverbear.org/2014/08/12/option-monads-in-rust/
- jhomedall 10y ago
  I've only looked at Rust in passing, but looking at the documentation, that example is pretty trivial. '.map' maps over the option. '.and_then' is the monadic bind operation, that you find in pretty much every modern programming language (frequently named 'flatMap'; even Java has this nowadays).
- Manishearth 10y ago
  You're redefining "control flow primitive". Those are not primitives, and they affect control flow as much as functions do, aside from `?`. Closures are a concept that C doesn't have, but once you get them they obfuscate nothing. These library calls obfuscate control flow only as much as regular function calls would. Nor are you forced to use code like the excessively clever version you talk of. People who are used to monadic programming have the choice to. You're making the same crappy arguments like a broken record. I'm not having the same tired old discussion again.
  - deleted 10y ago
    [deleted]

Animats 10y ago

Rust's control flow primitives are coming to be defined by libraries, not the language, and tend to grow over time. For a long time, we've been able to get by with a small, well-understood set of control flow primitives, those defined by Wirth many years ago. Now we have this in Rust: Type Option. The 2014 version.[1] The 2016 version.[2] (Coming soon, the "?" operator.[3]) Here's an example of excessive cleverness [4]: fn main () { let number: f64 = 20.; // Perform a pipeline of options. let result = Some(number) .map(inverse) .map(double) .map(inverse) .and_then(log) .map(square) .and_then(sqrt); // Extract the result. match result { Some(x) => println!("Result was {}.", x), None => println!("This failed.") } } (It's surprising that you can use .map on a singleton. Does this actually generate collections of one element and discard them, or what?) The designers of Go knew when to stop. The designers of Rust don't. [1] https://web.archive.org/web/20140814230239/http://doc.rust-lang.org/std/option/type.Option.html https://web.archive.org/web/20140814230239/http://doc.rust-l... [2] https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/enum.Option.html [3] https://github.com/rust-lang/rust/issues/31436 https://github.com/rust-lang/rust/issues/31436 [4] https://hoverbear.org/2014/08/12/option-monads-in-rust/ https://hoverbear.org/2014/08/12/option-monads-in-rust/

jhomedall 10y ago
I've only looked at Rust in passing, but looking at the documentation, that example is pretty trivial. '.map' maps over the option. '.and_then' is the monadic bind operation, that you find in pretty much every modern programming language (frequently named 'flatMap'; even Java has this nowadays).
Manishearth 10y ago
You're redefining "control flow primitive". Those are not primitives, and they affect control flow as much as functions do, aside from `?`. Closures are a concept that C doesn't have, but once you get them they obfuscate nothing. These library calls obfuscate control flow only as much as regular function calls would. Nor are you forced to use code like the excessively clever version you talk of. People who are used to monadic programming have the choice to. You're making the same crappy arguments like a broken record. I'm not having the same tired old discussion again.
- deleted 10y ago
  [deleted]