5 ms·

env::args().nth(1).unwrap_or("y".into()); this ridiculously complicated syntax to perform such a simple thing is why I will never accept Rust. What a clumsy, u

env::args().nth(1).unwrap_or("y".into()); this ridiculously complicated syntax to perform such a simple thing is why I will never accept Rust. What a clumsy, ugly language. I’ll just stick with learning ANSI common LISP, that pays immediate dividends.

0T-T0 9y ago
The only difference from expletive = 'y' if sys.argc == 1 else sys.argv[2] is the memory safety guards, which happens to be the key feature of Rust
- Annatar 9y ago
  But what if one doesn’t care about memory safety because one has other languages at one’s disposal, like shell, AWK, Lisp? What benefit does Rust bring then? And at what price? And who is to say that the programmers of Rust built a perfect language that always generates code which is bounds-safe? I question that as I know from experience that no human has ever written 100% correct code 100% of the time; even machines aren’t capable of achieving that. Therefore, I hold that the entire promise of Rust is flawed. I don’t like Rust one bit.
  - steveklabnik 9y ago
    We had a large community discussion about this last year: https://brson.github.io/fireflowers/ https://brson.github.io/fireflowers/
    - cat199 9y ago
      I don't think that theme is bright enough. Perhaps neon green with yellow letters would do the trick?
  - rurban 9y ago
    Problem is that Rust is not memory safe anymore, since they switched from GC to refcounting and added unsafe. Pair that with being no concurrency safety (deadlocks, races) there are only macros left which do make rust attractive. On the other side there are proper languages which do provide all safeties and beat rust or C++ in performance, such as pony. A proper type-system does help (compile-time guaranteed), but you could also add such features to the run-time system (e.g. a GC or safe threading with a single-writer system such as parrot). With rust you don't have any of it, you have to manually add locks or mutexes into your threaded code, and try to avoid unsafe.
simias 9y ago
It's fairly idiomatic so you get used to it but if you prefer something a little more C-ish you can write it like that (as a side note the code in TFA forgets to import std::env and BufWriter): use std::env::args; fn main() { let expletive = match args().nth(1) { Some(arg) => arg, None => "y".into(), }; loop { println!("{}", expletive); } } This is the equivalent to the unoptimized C version. I would argue that it's a little more readable too, substituting "loop" instead of the idiomatic "for(;;)" and the more verbose match syntax instead of the ternary (the terser rust equivalent being the `unwrap_or` you seemed to dislike). Personally I think I'd use the "unwrap_or" version, when you're familiar with the language it's completely transparent, easier to parse and expresses intent better I think. For an outsider I can see why it would look like a strange incantation though (but the same could be said about ternaries or CL's "do" construct for instance). The only thing I'd deem inelegant here is the `"y".into()`. It's probably not obvious what it does and why it's necessary to somebody not familiar with Rust.
- Annatar 9y ago
  That example is indeed more readable, but it still reads like methods on objects which is a fundamental issue for me. Any non trivial program written in an object-oriented paradigm eventually becomes incomprehensible, whereas the functional approach doesn’t rely on the state machine model. Two different approaches. I didn’t care for objects back in 1990 and I certainly care even less for them now. I upvoted your example in appreciation for the effort you went through though.
  - simias 9y ago
    I agree that for these types of constructs a more functional style could look better. That being said the OOP approach as the merit of reading in the proper order: you get your args, pick the 1st and then use that or the default "y" value. If you rewrite this to use function calls instead of methods you end up with something like: (or (cadr (args)) "y") Which is fine if you're used to lisp syntax but it's really a matter of taste at this point.
- deleted 9y ago

0T-T0 9y ago

The only difference from expletive = 'y' if sys.argc == 1 else sys.argv[2] is the memory safety guards, which happens to be the key feature of Rust

Annatar 9y ago
But what if one doesn’t care about memory safety because one has other languages at one’s disposal, like shell, AWK, Lisp? What benefit does Rust bring then? And at what price? And who is to say that the programmers of Rust built a perfect language that always generates code which is bounds-safe? I question that as I know from experience that no human has ever written 100% correct code 100% of the time; even machines aren’t capable of achieving that. Therefore, I hold that the entire promise of Rust is flawed. I don’t like Rust one bit.
- steveklabnik 9y ago
  We had a large community discussion about this last year: https://brson.github.io/fireflowers/ https://brson.github.io/fireflowers/
  - cat199 9y ago
    I don't think that theme is bright enough. Perhaps neon green with yellow letters would do the trick?
- rurban 9y ago
  Problem is that Rust is not memory safe anymore, since they switched from GC to refcounting and added unsafe. Pair that with being no concurrency safety (deadlocks, races) there are only macros left which do make rust attractive. On the other side there are proper languages which do provide all safeties and beat rust or C++ in performance, such as pony. A proper type-system does help (compile-time guaranteed), but you could also add such features to the run-time system (e.g. a GC or safe threading with a single-writer system such as parrot). With rust you don't have any of it, you have to manually add locks or mutexes into your threaded code, and try to avoid unsafe.

simias 9y ago

It's fairly idiomatic so you get used to it but if you prefer something a little more C-ish you can write it like that (as a side note the code in TFA forgets to import std::env and BufWriter): use std::env::args; fn main() { let expletive = match args().nth(1) { Some(arg) => arg, None => "y".into(), }; loop { println!("{}", expletive); } } This is the equivalent to the unoptimized C version. I would argue that it's a little more readable too, substituting "loop" instead of the idiomatic "for(;;)" and the more verbose match syntax instead of the ternary (the terser rust equivalent being the `unwrap_or` you seemed to dislike). Personally I think I'd use the "unwrap_or" version, when you're familiar with the language it's completely transparent, easier to parse and expresses intent better I think. For an outsider I can see why it would look like a strange incantation though (but the same could be said about ternaries or CL's "do" construct for instance). The only thing I'd deem inelegant here is the `"y".into()`. It's probably not obvious what it does and why it's necessary to somebody not familiar with Rust.

Annatar 9y ago
That example is indeed more readable, but it still reads like methods on objects which is a fundamental issue for me. Any non trivial program written in an object-oriented paradigm eventually becomes incomprehensible, whereas the functional approach doesn’t rely on the state machine model. Two different approaches. I didn’t care for objects back in 1990 and I certainly care even less for them now. I upvoted your example in appreciation for the effort you went through though.
- simias 9y ago
  I agree that for these types of constructs a more functional style could look better. That being said the OOP approach as the merit of reading in the proper order: you get your args, pick the 1st and then use that or the default "y" value. If you rewrite this to use function calls instead of methods you end up with something like: (or (cadr (args)) "y") Which is fine if you're used to lisp syntax but it's really a matter of taste at this point.
deleted 9y ago