5 ms·

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.