4 ms·
The syntax is ugly and can become overcrowded, but is in the HIGH side of readable. Compare: def read(path): What is path? Unknow. What it read? Unknow.
by mamcx 5y ago
The syntax is ugly and can become overcrowded, but is in the HIGH side of readable.
Compare:
def read(path):
What is path? Unknow. What it read? Unknow. What it return? Unknow
pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {
What is path? Anything that can become path on the file system.
What it read? Anything that can be pointed with that PATH
What it return? Vec of bytes or a IO::Error
PLUS: This code is compiled tot he exact types that call it, Path not allocate, the result can be cloned, the errors are defined in IO, ....
--
Rust is very readable: Almost any line tell you what is happening and what expect.
Where it get messy is when it hide that crucial info. But is not many times it happens.
- void_mint 5y agoIf you're talking about a language being readable to those that aren't proficient, Rust is about as bad as one could imagine. Your example is also less about Rust and more about type signatures.
- mamcx 5y ago> Your example is also less about Rust and more about type signatures. No, is HOW Rust use type signatures. Rust is in the camp of "advanced usage", not like C#, Python and others, where a "type" is barely for classification. Instead, Rust use types to inform: Memory type (heap vs stack), Cost (cheap to copy or must clone and can be potentially very big), Permisions (read/mutable), Behavior, Share-ability (can go in threads), lazy or not (iterable), etc. It use types for a lot, and communicate much information densely. P.D: Not always perfect and I agree that the syntax is not as nice to me, but is incredible how much you can understand from most codebases just reading, even on docs (not need IDE assistance that much)
- void_mint 5y ago> No, is HOW Rust use type signatures. No, I don't really agree. The example was "def read(path)", which is intentionally vague and any typed language would clarify. Your points can be/are valid, but they don't really change the fact that the above example was a cherry pick, and Rust's (over)use of symbols and special characters make it, again, about as hard to read as one could imagine. Just because you _can_ derive meaning from it doesn't change that.
- mamcx 5y agoOk, so how you do it or what can be used as counter-example?
- void_mint 5y agofunc Read (p Path) ([]byte, error) From your post: > What is path? Anything that can become path on the file system. > What it read? Anything that can be pointed with that PATH > What it return? Vec of bytes or a IO::Error
- rtpg 5y agoI think that types are definitely useful in one sense, but it's not all goodies. Things like `collect` end up in return-type polymorphism teritory that require you to grok the context in a sort of deeper way than, say, with random Java code.
- mamcx 5y agoYeah, the other side of the coin is idioms (like things that people understand as "pythonic" or idiomatic). Certain idioms not make much sense at first, but a big part of be on Rust is learn them. Eventually, most of it make sense and are very predictable (is incredible how much adherence exist for them in the whole community!).