3 ms·

What Rust really shines in is in making you handle things that need to be handled. For example: your user might input valid UTF-8 text as a filename for saving.

by atoav 2y ago

What Rust really shines in is in making you handle things that need to be handled. For example: your user might input valid UTF-8 text as a filename for saving. But not all filesystems allow all UTF-8 characters in filenames. Rust makes that explicit because it makes you convert the str/String to another special string type and forces you to handle errors in that conversion explicitly. Before I encountered that in Rust I have never even given it a thought, and I have been programming for years. And this is just one example, and also why I still recommend to anybody to learn Rust even if you will never use it. There are many valuable lessons in that language that will make you a better programmer in all other languages as well.

2OEH8eoCRo0 2y ago
Give programmers enough rope and they'll always hang themselves.
- sdwr 2y ago
  A bit morbid, but very true. You have to be exceptionally disciplined to keep a codebase tidy.
- atoav 2y ago
  My point was: It really depends on how you give them the rope. Is it a selection of ropes next to a cliff and 95% of the ropes will kill you without warning if you use it to go down it? Or it could be rope that prevents you from accidentally walking down the cliff, if you don't know it was there. Having a table saw that doesn't stop when it cuts wet material can be beneficial, but it is better to have one that stops when it hits your finger and where you can specifically deactivate the stopping-mechanism for the usecase of cutting slightly wet materials.
dataflow 2y ago
> you handle things that need to be handled. For example: your user might input valid UTF-8 text as a filename for saving. But not all filesystems allow all UTF-8 characters in filenames. Wait... isn't the usual problem that some filesystems allow invalid UTF sequences, rather than disallowing some valid ones? Or are you talking about ASCII characters like asterisks and colons? Also, don't all the idiosyncrasies differ per-filesystem, which... you won't even know until run time? How is converting to a different data type handling the things that need to be handled, when you have no idea what filesystem that data will be used for?
- estebank 2y ago
  > isn't the usual problem that some filesystems allow invalid UTF sequences, rather than disallowing some valid ones? It's both. > How is converting to a different data type handling the things that need to be handled, when you have no idea what filesystem that data will be used for? Because you make the translation once, early on, and handle failure then. For the rest of the program, you no longer have to perform those checks because the resulting value can only exist if the check was performed. > Also, don't all the idiosyncrasies differ per-filesystem, which... you won't even know until run time? Yes, the handling is at runtime, when making the transform from a string to a path, the result is a Result that needs to be handled, in some way.
  - dataflow 2y ago
    Are you saying you believe this conversion from a string to a path should involve I/O? Because it's literally impossible to validate a path's syntax without FS calls.
    - estebank 2y ago
      Rust's PathBuf uses an OsString as backing, which is merely a sparkling Vec<u8>. Displaying a PathBuf or OsString requires an explicit request to either validate that it is valid Unicode which can be handled by the caller, or for a "lossy string" where invalid Unicode codepoints get replaced with �. That's on the presentation side, going path -> user visible string. On the user provided string -> path case, if you start with accepting String then the conversion is merely a transmute, but some paths can't be represented by your users. If you allow any bytes to be passed in, taking from the user a Vec<u8>, then you can create an OsString and PathBuf without allocation while also allowing to represent any legal (and illegal) path. The verification of the legality of a path occurs when accessing a file, which is already a fallible operation that you must handle. The path might contain invalid characters for the FS, but the file might also just be missing, or inaccessible, so error handling at that point is not really optional. Note that Rust's PathBuf/Path don't do canonicalization by default, to account for symlinks and the like. If you want to canonicalize, you have fs::canonicalize which does FS calls to get the right path, and path::canonicalize which doesn't access the FS, assuming that foo/.. will be equivalent to .
kazinator 2y ago
I don't want to be writing conversion code between special string types with error handling in 2024. It's too braindamaged for words. And, first of all, burn that god forsaken filesystem. If the filesystem doesn't like a certain name, the OS should let you know. Handle that error and send it back to the user to choose a different name. You're not going to string-convert-and-error-handle your way out of the problem that the user cannot have the name that they specified.
- atoav 2y ago
  If you don't want to do that, you don't have to. You could just not interact with with filesystems you dislike. Or you could interact with it but purposefully ignore any error handling. The point I made is: this is an existing problem that could fail your mission critical code. Rust just tells you this could be a problem before it becomes one, it does not force you to care or pick a specific solution to solve the problem. With most other languages you would only find out about this error once it happens in production, if you ever find out about it. Going back to the user and asking them for a valid filename is also a form of error handling in my book. Of course ideally file systems would support all filenames and ideally they wouldn't suck, but we write software within a world that is not ideal.
  - kazinator 2y ago
    > Going back to the user and asking them for a valid filename is also a form of error handling in my book. You cannot get away from error handling because there are multiple reasons why a name cannot be used, not all of them having to do with its form. So, on Unix-like systems, do you use a special Rust string type which doesn't allow slashes or nulls? So that if the regular string fails to convert to that string, you know that it's not a valid name, and you get brownie points for having found that without passing it to the OS? Also, whenever you divide numbers a / b, always be sure to use a special numeric type for b which doesn't have zero in its domain. Then if the input type doesn't convert to that type, you know at compile time you could have a division by zero.
    - 2y ago

by atoav 2y ago

2OEH8eoCRo0 2y ago

Give programmers enough rope and they'll always hang themselves.

sdwr 2y ago
A bit morbid, but very true. You have to be exceptionally disciplined to keep a codebase tidy.
atoav 2y ago
My point was: It really depends on how you give them the rope. Is it a selection of ropes next to a cliff and 95% of the ropes will kill you without warning if you use it to go down it? Or it could be rope that prevents you from accidentally walking down the cliff, if you don't know it was there. Having a table saw that doesn't stop when it cuts wet material can be beneficial, but it is better to have one that stops when it hits your finger and where you can specifically deactivate the stopping-mechanism for the usecase of cutting slightly wet materials.

dataflow 2y ago

> you handle things that need to be handled. For example: your user might input valid UTF-8 text as a filename for saving. But not all filesystems allow all UTF-8 characters in filenames. Wait... isn't the usual problem that some filesystems allow invalid UTF sequences, rather than disallowing some valid ones? Or are you talking about ASCII characters like asterisks and colons? Also, don't all the idiosyncrasies differ per-filesystem, which... you won't even know until run time? How is converting to a different data type handling the things that need to be handled, when you have no idea what filesystem that data will be used for?

estebank 2y ago
> isn't the usual problem that some filesystems allow invalid UTF sequences, rather than disallowing some valid ones? It's both. > How is converting to a different data type handling the things that need to be handled, when you have no idea what filesystem that data will be used for? Because you make the translation once, early on, and handle failure then. For the rest of the program, you no longer have to perform those checks because the resulting value can only exist if the check was performed. > Also, don't all the idiosyncrasies differ per-filesystem, which... you won't even know until run time? Yes, the handling is at runtime, when making the transform from a string to a path, the result is a Result that needs to be handled, in some way.
- dataflow 2y ago
  Are you saying you believe this conversion from a string to a path should involve I/O? Because it's literally impossible to validate a path's syntax without FS calls.
  - estebank 2y ago
    Rust's PathBuf uses an OsString as backing, which is merely a sparkling Vec<u8>. Displaying a PathBuf or OsString requires an explicit request to either validate that it is valid Unicode which can be handled by the caller, or for a "lossy string" where invalid Unicode codepoints get replaced with �. That's on the presentation side, going path -> user visible string. On the user provided string -> path case, if you start with accepting String then the conversion is merely a transmute, but some paths can't be represented by your users. If you allow any bytes to be passed in, taking from the user a Vec<u8>, then you can create an OsString and PathBuf without allocation while also allowing to represent any legal (and illegal) path. The verification of the legality of a path occurs when accessing a file, which is already a fallible operation that you must handle. The path might contain invalid characters for the FS, but the file might also just be missing, or inaccessible, so error handling at that point is not really optional. Note that Rust's PathBuf/Path don't do canonicalization by default, to account for symlinks and the like. If you want to canonicalize, you have fs::canonicalize which does FS calls to get the right path, and path::canonicalize which doesn't access the FS, assuming that foo/.. will be equivalent to .

kazinator 2y ago

I don't want to be writing conversion code between special string types with error handling in 2024. It's too braindamaged for words. And, first of all, burn that god forsaken filesystem. If the filesystem doesn't like a certain name, the OS should let you know. Handle that error and send it back to the user to choose a different name. You're not going to string-convert-and-error-handle your way out of the problem that the user cannot have the name that they specified.

atoav 2y ago
If you don't want to do that, you don't have to. You could just not interact with with filesystems you dislike. Or you could interact with it but purposefully ignore any error handling. The point I made is: this is an existing problem that could fail your mission critical code. Rust just tells you this could be a problem before it becomes one, it does not force you to care or pick a specific solution to solve the problem. With most other languages you would only find out about this error once it happens in production, if you ever find out about it. Going back to the user and asking them for a valid filename is also a form of error handling in my book. Of course ideally file systems would support all filenames and ideally they wouldn't suck, but we write software within a world that is not ideal.
- kazinator 2y ago
  > Going back to the user and asking them for a valid filename is also a form of error handling in my book. You cannot get away from error handling because there are multiple reasons why a name cannot be used, not all of them having to do with its form. So, on Unix-like systems, do you use a special Rust string type which doesn't allow slashes or nulls? So that if the regular string fails to convert to that string, you know that it's not a valid name, and you get brownie points for having found that without passing it to the OS? Also, whenever you divide numbers a / b, always be sure to use a special numeric type for b which doesn't have zero in its domain. Then if the input type doesn't convert to that type, you know at compile time you could have a division by zero.
  - 2y ago