8 ms·

As a side note, looking at this block of code, the syntax is just so ugly and overcrowded. I don't get how a relatively new language ended up looking so messy s

• capableweb 5y ago
  It is what usually happens when you design by committee instead of everyone having a common understanding and working towards the same goal under a single person/entity. Not saying it's good or bad, just how Rust ended up where it is.
  • deleted 5y ago
    [deleted]
  • pcwalton 5y ago
    What Rust committee?
    • capableweb 5y ago
      "Design by committee" - https://en.wikipedia.org/wiki/Design_by_committee https://en.wikipedia.org/wiki/Design_by_committee I disagree it's a pejorative term as Wikipedia puts it though. Design by committee is in many cases necessary or even wanted (standard bodies).
• Zababa 5y ago
  I find the syntax very readable. What's your problem with it?
  • kbenson 5y ago
    I imagine it's that there's a fairly high ratio if function signatures to other lines of code, and function signatures are particularly gnarly in rust compared to many other languages, at least when lifetimes are involved.
    • Zababa 5y ago
      I agree that I find lifetimes a bit hard to read, but outside of that I usually find Rust's syntax really clear for an algol-like. For example, they use the ML-style type declaration variable: type, which I find more readable than the C-like type variable. There's a different syntax for namespace and function chaining, which I also like.
    • infogulch 5y ago
      I wonder if this is a side-effect of rust function signatures being very precise, as in the function is very clear about the allowable type and ownership of its parameters and return values, where most languages can't even express things at that level of precision so people's eyes glaze over when reading it.
      • kbenson 5y ago
        I imagine so. A function signature is rust encodes more information than a lot of other languages. From my (very) limited experience, without lifetimes they look fairly similar to C++, and then adding lifetimes just makes them busier and more complex, but that's because you're encoding additional information.
  • jakobnissen 5y ago
    Compare to Julia # Your big function has specific types function my_function(x::UInt, y::UInt) [ ... ] end # Wrapper function to minimize monomorph. cost my_function(x::Integer, y::Integer) = my_function(UInt(x), UInt(y))
    • Zababa 5y ago
      Your comparaison isn't only about syntax, it's also about the presence or absence of static types.
      • jakobnissen 5y ago
        Those two are related, clearly. It's not that Rust has added words that literally do nothing. Instead, the designers of Rust packed all kinds of things into the syntax that other languages decided would cause too much noise. * The output type must be explicitly named instead of inferred * The let keyword for creation of variables instead of merely assignment * The mut keyword to distinguish between mutable/immutable variables * The pub keyword, instead of another mechanism * Semicolons needed after every expression And more. Again, for every one of them, you can argue that it's _good_ for it to be there, because it serves a function. But you end up with a language with a hugely bloated syntax where the business logic is sort of swamped in these accessory keywords.
        • Zababa 5y ago
          I don't agree that the syntax is "hugely bloated". The return type is part of the business logic. mut and pub are here to make some things explicit, so again I don't mind them. Rust is one of those languages that wants to make more things explicit because the people using it need those things to be explicit.
        • tialaramex 5y ago
          > The output type must be explicitly named instead of inferred That isn't syntax. It's a decision about analysis. > The pub keyword, instead of another mechanism The "other mechanisms" discussed are in fact not providing this feature, but pretending you needn't care, and I'd argue Rust shows that in fact you should care and pretending otherwise is a problem. > Semicolons needed after every expression On the contrary, semicolons are at the end of Rust's statements. If what you've got is an expression you don't need a semicolon. For example here's how log is defined on an f64 (a double precision floating point number) pub fn log(self, base: f64) -> f64 { self.ln() / base.ln() } Notice there's no semicolon there because that function is an expression, we want the value of this division as the result of the function.
• scottlamb 5y ago
  Partly personal preference in both what is readable and in how much you optimize caller convenience vs simple callee code. I think it's fine to just expect the caller to do the conversion. In fact, it's often automatic. (Eg if you have a PathBuf, then just sticking a & in front of it is sufficient to supply &Path via Deref<Target = Path>.) So I'd write this function as follows: fn read(path: &Path) -> io::Result<Vec<u8>> { let mut file = File::open(path)?; let mut bytes = Vec::new(); file.read_to_end(&mut bytes)?; Ok(bytes) } which I find readable. Comparing to another language...I haven't written Go in a while, but I think the rough equivalent would be: func Read(path *Path) ([]byte, error) { file, err := os.Open(path) if err != nil { return nil, err } slice, err := io.ReadAll(file) if err != nil { return nil, err } return slice, nil } (Maybe in this case you'd just return the io.ReadAll rather than doing an if, but I'm trying to use similar constructs. The ? is something you can use all throughout the function, not just at the end, so I tried to match that pattern.) [edited: I said there wasn't a io.ReadToEnd extracted from io.ReadFile in Go, but jatone pointed out it's called io.ReadAll.]
  • capableweb 5y ago
    I don't know Rust but converting that code snippet of Go code you wrote to (non-idiomatic [wouldn't use upper-case characters, namespaces used doesn't actually exists]) Clojure: (defn Read [path] (io/ReadToEnd (os/Open path))) Now that's what I call readable!
    • brundolf 5y ago
      Clojure is also a much higher-level language than Rust (and arguably Go too)
    • scottlamb 5y ago
      You can chain calls in Rust. If read_to_end were written to allocate and return a fresh Vec, you could do this: File::open(path)?.read_to_end() but instead read_to_end is written to take a presupplied Vec so the caller has the option to reduce allocations.
• nextaccountic 5y ago
  The worst decision regarding Rust syntax was following C++ syntax. Due to this, we write, in type syntax Things<Like<This, That>, That> -- as in C++ Instead of a more legible (and very familiar to Rust authors) Things (Like This That) That -- as in Haskell Inherited from C++, we had also :: for namespacing (while a dot . could be perfectly be used for that), and tons of other stuff like <> for scoping generics. Without some of that we could have: pub fn read<P: AsRef Path>(path: P) -> io.Result (Vec u8) { fn inner(path: &Path) -> io.Result (Vec u8) { let mut file = File.open(path)?; let mut bytes = Vec.new(); file.read_to_end(&mut bytes)?; Ok(bytes) } inner(path.as_ref()) } Perhaps it looks a little better? It looks for me, at least. For doing better than that we could drop C-like syntax perhaps? The trouble is that languages have a weirdness budget - there's a finite amount of novel stuff a language can have until it becomes too weird for mainstream programmers. So language designers have to pick their weird features carefully. Spending it all in novel syntax is unwise. I think that at the time the Rust pull was safety for low level code and, as Rust was targeted to replace some C++ components, following C++ syntax was seen as a good idea.
  • axelf4 5y ago
    Surely mixing usage of space and parentheses for function application is a bad idea?
    • nextaccountic 5y ago
      But I'm not talking about function application - I'm talking about type application. The syntax of type application and function application is already different in rust: F<A, B> vs f(a, b). Type application even has default and named parameters! F<X = A, Y = B> and F<A> if B has a default. I just think this particular type-level syntax is very noisy, specially because types in Rust tend to be very nested.
  • Zababa 5y ago
    I like how the namespace and the function chaining have different characters. I think it makes it easier to read.
  • 5y ago
• OJFord 5y ago
  To take a guess at what you don't like, it can be equivalently spaced out a bit more like: pub fn read<P>(path: P) -> io::Result<Vec<u8>> where P: AsRef<Path>, { And of course if you were using a lot of u8 vec results, you might create a shorter alias for that.
• tanaypingalkar 5y ago
  I think rust syntax is more readable and self explains. Having syntax more minimal, more use of symbols, spaces and tab make them beautiful but they are really hard to get if it is written by someone else. I personally noticed it's more easy understand other rust project than other langs project.
• 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 ago
    If 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.
• pcwalton 5y ago
  Come on, it is definitely not the case that nobody cared about readability. My sleepless nights after arguments about syntax in 2011 and 2012 very much say otherwise.
  • steveklabnik 5y ago
    Or the endless arguments about await, or that time I cried because the discussion over what we call integers was so contentious. We all cared quite a bit about syntax. Heck that’s partially why almost none of it is novel!
    • matklad 5y ago
      I don’t think that when people say “Rust has ugly syntax” they mean that Rust has ugly syntax. It seems that what they are complaining about is actually Rust semantics, which needs extra syntax to express it. Blog post idea: express this snippet (with references, aliasing control, generics and all) in pseudo C++, Java, Python, etc. Then express “reading a file in gc language with exceptions” in pseudo Rust.
• scrubs 5y ago
  Agree.
• catern 5y ago
  One sad aspect is the ? operator. In the beginning, Rust thought it could get away with explicitly handled return codes, without having support for direct style/exceptional error handling. But they've ended up with that in the end. If Rust had just used checked exceptions from the start (or equivalently if they had do-notation) they wouldn't have this lingering syntactic noise. Hindsight is 20/20 though - it would have been hard to convincingly predict that Rust would eventually end up with checked-exceptions-plus-syntactic-noise as its error handling paradigm - the experiment had to be carried out to see that it would end up like this. (Now, of course, exceptions have been thoroughly vindicated, and it would be silly to design a new language with explicitly handled return codes instead of checked exceptions)
  • zozbot234 5y ago
    ? is not "syntactic noise". Having an indication in the code of which operations might throw is very useful, and it enables a further simplification of using ordinary variant records as opposed to a special-cased "checked exception" construct.
    • catern 5y ago
      Compare it to unsafe functions. An unsafe function can be called in an unsafe block or an unsafe function. Rust could require annotating each call to an unsafe function, even inside unsafe functions. Why don't we do that? That seems like it's also very useful for the exact same reasons. A proper language needs to allow the programmer to choose between implicit effects and explicit effects on a case-by-case basis. The reason ? is so tragic is because Rust tried to go with explicit effects only, but found that people wanted implicit effects, and ? is the closest that Rust can get. That's why it's syntactic noise: The programmer wants to get rid of it, they don't regard it as informative for this case, but they can't get rid of it. (And checked exceptions can be perfectly well implemented with regular data, you don't need any special cases - in fact, you can do it with the same infrastructure that's already been added in a special-cased form for async/await support...)
      • GolDDranks 5y ago
• bschwindHN 5y ago
  I think the language team has done a great job. Rust may look a little ugly on the surface if you're just getting into it, but I'm super thankful they opted to require functions to always spell out all type signatures. Generics can get a little overwhelming but like any other skill, it just takes a few hours/days of practice to learn how to read them.
• runeks 5y ago
  Do you have any constructive suggestions? It looks pretty readable to me, and I’ve never written any Rust.