4 ms·

One of the reasons why I haven't approached Rust is its syntax. Subjectively ugly and polluted with punctuation symbols that tell you little about their semanti

One of the reasons why I haven't approached Rust is its syntax. Subjectively ugly and polluted with punctuation symbols that tell you little about their semantics. D looks cleaner and more readable even for a person not familiar with the language. D's readability is on par with scripting languages. Rust is far away from that. Type names after variable or before? When you think about declaring a variable, do you think about its type of name first? I can't imagine you do the latter because "Hmm, I need an array of doubles to represent my tensor" is double[][] tensor; and not tensor: double[][]. Besides the types after names end up being more verbose in the languages which adopt the scheme (hello Scala). I invite you to get familiar with D syntax to see a wider picture. The borrow checker in D is WIP and given how much stir it created, I don't see it's happening any time soon.

vvillena 6y ago
The reason behind putting the type after the variable is that the resulting syntax plays way better with type inference. Scala is a clear inspiration for Rust in that regard.
- tastyminerals2 6y ago
  (Let me nip a little here). Looks like not only Scala inference types but also its compile times too migrated into Rust.
  - vvillena 6y ago
    Hahaha, it's true that Rust compile times are slower than its main competitors, due to the amount of work the compiler does. It's the same with Scala: even if some abstractions in both languages are zero- or low-cost during runtime, they still slow down compile times. In any case, as a Scala dev, I wish the compile times were as short as in Rust!
zucker42 6y ago
> When you think about declaring a variable, do you think about its type of name first? I completely disagree with your opinion on this subject, though I recognize that it's mostly subjective. I think types after the variable are completely better except for my muscle memory from C.
CDSlice 6y ago
The nice thing about Rust is you often don’t have to declare the type of a variable since the compiler will just infer it for you. This is especially nice in an IDE like CLion which will show you the inferred type for each variable. As for the syntax for a type declaration, `variable: Type` is more natural and readable for me than `type variable`. The first one naturally reads as `variable is a Type` while the second reads like Yoda speak (`A Type, variable is`) Since I am not familiar with Scalia, I am not sure why the types after the name would end up being more verbose, as far as I can tell the only difference is the : between the variable and its type. Would you mind expanding on that? Personally although Rust definitely does not have the elegance of Haskell or Python, I definitely would not call it ugly. There aren’t that many symbols and once you actually spend the time to learn the language the semantics for each syntax element are pretty easy to remember. I also have looked at D, but the lack of algebraic data types makes it a non-starter for me.
thomastjeffery 6y ago
> Type names after variable or before? When you think about declaring a variable, do you think about its type of name first? I can't imagine you do the latter because "Hmm, I need an array of doubles to represent my tensor" is double[][] tensor; and not tensor: double[][]. You can just as equally think of it as, "I need my tensor to be an array of doubles". That works much more cleanly with type inference, because the type is more of an annotation, and you can drop it without adding the boilerplate word "auto". > Subjectively ugly and polluted with punctuation symbols that tell you little about their semantics. Like what?
e_y_ 6y ago
For reading code, which arguably should happen more often than writing code, having the variable name first makes it easier to find, since it's right near the beginning of the line and it's a single word. If the type comes first, I have to scan the line to figure out where the type ends and the variable name begins. Also, having "let" at the beginning of the line makes it immediately clear that it's a variable definition, whereas if it starts with some arbitrary type I haven't seen before I have to spend more time figuring out what's happening. Good syntax highlighting helps, but I think starting with types like C/C++/D is less elegant than starting off with a keyword that clearly identifies what the line does. Similar applies for function definitions. It's nice when the function names are all lined up and not buried halfway across the screen because it has some long return type.
- tastyminerals2 6y ago
  Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Why would you want to explicitly tell that something is a value while all you need to do is write its type and name? double[] arr; bam! Simple and clear. What about functions? It has input, name and output and D nicely presents you with double[] createArray(int size) {...} This is as little typing as you can get while keeping readability. And here is a basic Rust function fn add_one(x: i32) -> i32 {...} What kind of type is i32 btw? oh, there is u32 as well. integer 32bit and unsigned 32bit? What on earth are these? Ah, this is just D's size_t, the same size_t as in C/C++. So that C/C++ ppl have zero overhead reading D code and for Rust they will google. To top that, you have also -> because of the type after the definition scheme. Needless verbosity, same thing in Scala. What about Rust unable to drop parenthesis after a function? self.host_addr.clone() Should I mention Rust's UFCS? But I am nitpicking, right. This doesn't make a language bad in any way. However, as I said, Rust readability is pretty subpar in addition to already steep language learning curve.
  - skocznymroczny 6y ago
    You are nitpicking. size_t is architecture dependent, on x86 it will usually be 32-bit, on x86_64 it will be usually 64-bit. It's not equivalent to i32, u32 types. Also, I find i32 and u32 types much cleaner than D's "unsigned int" and "int". What is the difference between "unsigned int" and "unsigned long" in D? It's still better than C++, but I'd rather write i32 and i64 rather than "int" and "long".

vvillena 6y ago

The reason behind putting the type after the variable is that the resulting syntax plays way better with type inference. Scala is a clear inspiration for Rust in that regard.

tastyminerals2 6y ago
(Let me nip a little here). Looks like not only Scala inference types but also its compile times too migrated into Rust.
- vvillena 6y ago
  Hahaha, it's true that Rust compile times are slower than its main competitors, due to the amount of work the compiler does. It's the same with Scala: even if some abstractions in both languages are zero- or low-cost during runtime, they still slow down compile times. In any case, as a Scala dev, I wish the compile times were as short as in Rust!

zucker42 6y ago

> When you think about declaring a variable, do you think about its type of name first? I completely disagree with your opinion on this subject, though I recognize that it's mostly subjective. I think types after the variable are completely better except for my muscle memory from C.

CDSlice 6y ago

The nice thing about Rust is you often don’t have to declare the type of a variable since the compiler will just infer it for you. This is especially nice in an IDE like CLion which will show you the inferred type for each variable. As for the syntax for a type declaration, `variable: Type` is more natural and readable for me than `type variable`. The first one naturally reads as `variable is a Type` while the second reads like Yoda speak (`A Type, variable is`) Since I am not familiar with Scalia, I am not sure why the types after the name would end up being more verbose, as far as I can tell the only difference is the : between the variable and its type. Would you mind expanding on that? Personally although Rust definitely does not have the elegance of Haskell or Python, I definitely would not call it ugly. There aren’t that many symbols and once you actually spend the time to learn the language the semantics for each syntax element are pretty easy to remember. I also have looked at D, but the lack of algebraic data types makes it a non-starter for me.

thomastjeffery 6y ago

> Type names after variable or before? When you think about declaring a variable, do you think about its type of name first? I can't imagine you do the latter because "Hmm, I need an array of doubles to represent my tensor" is double[][] tensor; and not tensor: double[][]. You can just as equally think of it as, "I need my tensor to be an array of doubles". That works much more cleanly with type inference, because the type is more of an annotation, and you can drop it without adding the boilerplate word "auto". > Subjectively ugly and polluted with punctuation symbols that tell you little about their semantics. Like what?

e_y_ 6y ago

For reading code, which arguably should happen more often than writing code, having the variable name first makes it easier to find, since it's right near the beginning of the line and it's a single word. If the type comes first, I have to scan the line to figure out where the type ends and the variable name begins. Also, having "let" at the beginning of the line makes it immediately clear that it's a variable definition, whereas if it starts with some arbitrary type I haven't seen before I have to spend more time figuring out what's happening. Good syntax highlighting helps, but I think starting with types like C/C++/D is less elegant than starting off with a keyword that clearly identifies what the line does. Similar applies for function definitions. It's nice when the function names are all lined up and not buried halfway across the screen because it has some long return type.

tastyminerals2 6y ago
Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Why would you want to explicitly tell that something is a value while all you need to do is write its type and name? double[] arr; bam! Simple and clear. What about functions? It has input, name and output and D nicely presents you with double[] createArray(int size) {...} This is as little typing as you can get while keeping readability. And here is a basic Rust function fn add_one(x: i32) -> i32 {...} What kind of type is i32 btw? oh, there is u32 as well. integer 32bit and unsigned 32bit? What on earth are these? Ah, this is just D's size_t, the same size_t as in C/C++. So that C/C++ ppl have zero overhead reading D code and for Rust they will google. To top that, you have also -> because of the type after the definition scheme. Needless verbosity, same thing in Scala. What about Rust unable to drop parenthesis after a function? self.host_addr.clone() Should I mention Rust's UFCS? But I am nitpicking, right. This doesn't make a language bad in any way. However, as I said, Rust readability is pretty subpar in addition to already steep language learning curve.
- skocznymroczny 6y ago
  You are nitpicking. size_t is architecture dependent, on x86 it will usually be 32-bit, on x86_64 it will be usually 64-bit. It's not equivalent to i32, u32 types. Also, I find i32 and u32 types much cleaner than D's "unsigned int" and "int". What is the difference between "unsigned int" and "unsigned long" in D? It's still better than C++, but I'd rather write i32 and i64 rather than "int" and "long".