8 ms·

I had the same experience with Rust too. After trying and failing for hours to trudge through syntax BS, I'm (probably) not touching it again until something bi

I had the same experience with Rust too. After trying and failing for hours to trudge through syntax BS, I'm (probably) not touching it again until something big changes. I can't even get user input without making a huge ugly one-liner or importing some dependency.

nneonneo 4y ago
Unclear what you mean by user input - for arguments, `std::env::args()` exists, and for stdin `std::io::stdin()` exists and provides various read functions. let mut line = String::new(); stdin().read_line(&mut line)?; println!("input: {}", line); I suspect that there _have_ been some changes since you last looked - for example, the ? operator lets you propagate errors in a more compact way.
- netr0ute 4y ago
  let mut line = String::new(); stdin().read_line(&mut line)?; This is what I'm talking about. This is so ugly and clunky and needlessly verbose like Java compared to C++ where you can do std::string input; std::cin >> input; and have it Just Work. Why can't Rust do something similar?
  - nneonneo 4y ago
    Except, you've failed to check for an error, and you need another line to do that. Suppose the user ended their input or the input is a pipe that's been closed - what does your C++ program do? Here's another example. C++ lets you do this: long input; std::cin >> input; process(input); and this is very convenient! It's much shorter than the Rust code for doing the same. It's also wrong! If the input cannot be read, or it cannot be parsed as an integer, `input` now contains undefined content. You'd need to remember to check the contents, or end up processing undefined memory values. You cannot make this error in Rust without a lot of contortions (e.g. unsafe). Some people will say, I just want to get stuff done and not worry about all this safety junk. As someone who works in security and have exploited bugs in C/C++ programs, this is pretty much why we wound up with so many CVEs.
    - netr0ute 4y ago
      > Some people will say, I just want to get stuff done and not worry about all this safety junk. As someone who works in security and have exploited bugs in C/C++ programs, this is pretty much why we wound up with so many CVEs. Are constructions like these really the root cause of CVEs? As long as you do a correct check, then you're all good. If Rust can do the same thing in fewer lines, then that may or may not be a good thing because some people might want a lower degree of abstraction or a greater one.
      - nneonneo 4y ago
        Oh absolutely! Here’s an example from 2019: https://www.cve.org/CVERecord?id=CVE-2019-15900 https://www.cve.org/CVERecord?id=CVE-2019-15900 “An issue was discovered in slicer69 doas before 6.2 on certain platforms other than OpenBSD. On platforms without strtonum(3), sscanf was used without checking for error cases. Instead, the uninitialized variable errstr was checked and in some cases returned success even if sscanf failed. The result was that, instead of reporting that the supplied username or group name did not exist, it would execute the command as root.” Fail to check that your input parsed correctly, wind up with privilege escalation to root.
        netr0ute 4y ago
        The problem here is that that implementation was written in plain old C and is super unsafe, and is NOT C++. I don't know why C keeps getting confused with C++ because the two are basically totally different now.
        nneonneo 4y ago
        Oh my bad! That must be why C++, a definitely not super unsafe language that is basically totally different from C, lets you do this: char buf[10]; std::cin >> buf; std::cout << buf << std::endl; g++ -Wall -std=c++2a (sorry, I’ve only got GCC 9), no warnings or errors, happily overruns the stack when fed more than 10 characters. This code is essentially equivalent to the C gets(buf) (splitting on whitespace instead of newline), but gets is deprecated and generates big warnings on most modern C compilers. Yet, operator>>(char *) does not. Sure, you can write secure code in C++. You can write secure code in C too, even if that language is “super unsafe”. But neither language will stop you from writing insecure code either.
  - masklinn 4y ago
    Because Rust does not want to have implicit constructors, default constructors, constructors at all, random statics, ... And `std::cin` does not read a line from the input, you need `getline` for that.
  - oll3 4y ago
    Not that this kind of stdin reading operation is something I do often. But at least the Rust code says what it does. Bitshifting stdin by a string on the other hand... Does it read a line, or forever, or read at all? I wouldn't call it the ultimate syntax for a line reader anyway. :)

nneonneo 4y ago

Unclear what you mean by user input - for arguments, `std::env::args()` exists, and for stdin `std::io::stdin()` exists and provides various read functions. let mut line = String::new(); stdin().read_line(&mut line)?; println!("input: {}", line); I suspect that there _have_ been some changes since you last looked - for example, the ? operator lets you propagate errors in a more compact way.

netr0ute 4y ago
let mut line = String::new(); stdin().read_line(&mut line)?; This is what I'm talking about. This is so ugly and clunky and needlessly verbose like Java compared to C++ where you can do std::string input; std::cin >> input; and have it Just Work. Why can't Rust do something similar?
- nneonneo 4y ago
  Except, you've failed to check for an error, and you need another line to do that. Suppose the user ended their input or the input is a pipe that's been closed - what does your C++ program do? Here's another example. C++ lets you do this: long input; std::cin >> input; process(input); and this is very convenient! It's much shorter than the Rust code for doing the same. It's also wrong! If the input cannot be read, or it cannot be parsed as an integer, `input` now contains undefined content. You'd need to remember to check the contents, or end up processing undefined memory values. You cannot make this error in Rust without a lot of contortions (e.g. unsafe). Some people will say, I just want to get stuff done and not worry about all this safety junk. As someone who works in security and have exploited bugs in C/C++ programs, this is pretty much why we wound up with so many CVEs.
  - netr0ute 4y ago
    > Some people will say, I just want to get stuff done and not worry about all this safety junk. As someone who works in security and have exploited bugs in C/C++ programs, this is pretty much why we wound up with so many CVEs. Are constructions like these really the root cause of CVEs? As long as you do a correct check, then you're all good. If Rust can do the same thing in fewer lines, then that may or may not be a good thing because some people might want a lower degree of abstraction or a greater one.
    - nneonneo 4y ago
      Oh absolutely! Here’s an example from 2019: https://www.cve.org/CVERecord?id=CVE-2019-15900 https://www.cve.org/CVERecord?id=CVE-2019-15900 “An issue was discovered in slicer69 doas before 6.2 on certain platforms other than OpenBSD. On platforms without strtonum(3), sscanf was used without checking for error cases. Instead, the uninitialized variable errstr was checked and in some cases returned success even if sscanf failed. The result was that, instead of reporting that the supplied username or group name did not exist, it would execute the command as root.” Fail to check that your input parsed correctly, wind up with privilege escalation to root.
      - netr0ute 4y ago
        The problem here is that that implementation was written in plain old C and is super unsafe, and is NOT C++. I don't know why C keeps getting confused with C++ because the two are basically totally different now.
        nneonneo 4y ago
        Oh my bad! That must be why C++, a definitely not super unsafe language that is basically totally different from C, lets you do this: char buf[10]; std::cin >> buf; std::cout << buf << std::endl; g++ -Wall -std=c++2a (sorry, I’ve only got GCC 9), no warnings or errors, happily overruns the stack when fed more than 10 characters. This code is essentially equivalent to the C gets(buf) (splitting on whitespace instead of newline), but gets is deprecated and generates big warnings on most modern C compilers. Yet, operator>>(char *) does not. Sure, you can write secure code in C++. You can write secure code in C too, even if that language is “super unsafe”. But neither language will stop you from writing insecure code either.
- masklinn 4y ago
  Because Rust does not want to have implicit constructors, default constructors, constructors at all, random statics, ... And `std::cin` does not read a line from the input, you need `getline` for that.
- oll3 4y ago
  Not that this kind of stdin reading operation is something I do often. But at least the Rust code says what it does. Bitshifting stdin by a string on the other hand... Does it read a line, or forever, or read at all? I wouldn't call it the ultimate syntax for a line reader anyway. :)