4 ms·

Newb Question: Why didn't Rust go with an easier to read syntax? Why did they stick to old C syntax? Edit/ Sorry, didn't mean to offend anyone.

steveklabnik 7y ago
“Easy to read” is relative to your audience. For our initial target audience, systems programmers, C style syntax is what’s easier for them to read. We did diverge where we felt it was appropriate.
rkangel 7y ago
While there is some objective, measurable aspect to 'easier to read' it is mostly dominated by what someone is used to. The only C style syntax that's used is block grouping (curly braces), and statement separation (semicolon). Unless you go for using whitespace to perform those functions, you're making fairly arbitrary choices about which symbol to use, and those two are familiar. Most other syntax is really quite different: * variable definition has a completely different order to it with (optional) type ascription * function definition has some aspects of C++ (<> for types in generic functions) but much else is different - e.g. position of return type, where clauses, the 'fn' keyword, type ascription
ohazi 7y ago
I don't think I'd describe Rust's syntax as C-like. What gives you that impression? The only resemblance I see is curly braces. Rust doesn't even have a C-style for loop. If anything, Rust's syntax can be confusing because the order of names and types are reversed compared to C. This is a trend that a lot of recent languages are returning to because it can simplify the parser. Also backtick lifetime parameters, but that's a feature that no other mainstream language has, so it was bound to be a little confusing regardless of the syntax.
- gattr 7y ago
  To be precise: lifetimes are denoted by an apostrophe. (Backtick can be used in comments for Markdown formatting.)
- Myrmornis 7y ago
  I would certainly describe Rust's syntax as being in the family of C-like syntaxes. Function calls use function named followed by positional args in smooth parens, curly braces for blocks, & and * for pointers/references, if/continue/break/while, semicolon termination, square bracket indexing of array/vec, etc etc. It's very obviously a descendent of the C syntax family. Of course it has several critical extensions related to impl, generics, lifetimes, references, modules etc, partly influenced by C++ (e.g. generics syntax), Ruby (closure) and Python (self). It depends on your perspective, but if the scope is all programming languages, then Rust is syntactically very close to C.
kjeetgill 7y ago
Which syntax do you prefer? Lisp or python or php styles? That is pretty much your answer: It's subjective. Off the top of my head, I'd imagine that familiarity for the huge pool of C/C++/Java/C# programmers was probably a huge push for the chosen syntax.
jcranmer 7y ago
For most programmers, a C-ish syntax is going to be most familiar. In general, I'd define the "universal C-ish syntax" as: * Ending statements with ; * {} for braces, lowercase keywords for control flow * [] and 0-based indexing for arrays * Infix operator notation, with mathematical operator precedence * &, |, ^, ~ for bitwise operators * . is used for member access But they didn't copy all of C's syntax: * There's no ->, since dereference is usually automatic. * No ?:, if/else can be used as expressions instead * No ~, since ! on an integer variable does bitwise negation instead. * Pointer, array, and function types don't have the weird syntax they do in C... you say [ * mut fn()->i32; 4] instead of int ( * ())[4] * Types follow variables instead of precede them (x: i32 instead of int x) * No C-style casts (x as i32 instead of (int)x)
- dragonwriter 7y ago
  > There's no ->, Well, there is, but it's more like ML’s -> than C’s ->.
- gjm11 7y ago
  I was going to make a snarky comment to the effect that the Rust syntax for an array of pointers to functions isn't obviously less weird than the C syntax -- I assume the basic thing there is [<type>; <size>] -- but then I noticed that the C syntax above was very wrong, and the correct syntax is weirder :-). So what it should actually be is int ( * [4])(). The principle is that "declaration mimics use" and that a type is written like a declaration with the variable name omitted. So, for an array of pointers to functions mapping no-args to int: If f is such a function, you would call it as f() and get an int, so the declaration would look like int f() and the type would be int () except that functions, as opposed to function pointers, aren't first-class objects in C and don't have a type. If pf is a pointer to such a function, you would need ( * pf) instead of f, so the declaration would be int ( * pf)() and the type would be int ( * )(). If apf is an array of those, then you would need to replace pf with apf[something], so the declaration would be int ( * apf[4])() and the type would be int ( * [4])(). Which is, indeed, a bit weird. (Note: Spaces around all the asterisks because that seems to be the least-bad way of making HN not interpret them as markup. It's quite impressive how damaging HN's markup feature manages to be given how little it's capable of.)
mamcx 7y ago
Because audience. Sadly C/C++ dominate and that spread elsewhere. However "hard to read" is also the many concepts that rust have and certainly the combination of traits/lifetimes make some stuff very obtuse.
dragonwriter 7y ago
> Why did they stick to old C syntax? Did they? Rust always seems to me to a pretty free mix of C, Ruby-ish, and ML syntax (and an amazingly well chosen mix, because that description makes me want to run away from it, but the reality is pretty nice.)
- Myrmornis 7y ago
  I'm not really going to complain about syntax, but if I were... the only thing I don't like is the Ruby vertical bars around closure formal arguments. ES6 smooth parens and double arrows seem so much more fitting to a function to me. (I mostly write Python). I guess double arrows are used in match and single arrow in function return types, but if there had been a way to use arrows for closures I'd have voted for that.

steveklabnik 7y ago

“Easy to read” is relative to your audience. For our initial target audience, systems programmers, C style syntax is what’s easier for them to read. We did diverge where we felt it was appropriate.

rkangel 7y ago

While there is some objective, measurable aspect to 'easier to read' it is mostly dominated by what someone is used to. The only C style syntax that's used is block grouping (curly braces), and statement separation (semicolon). Unless you go for using whitespace to perform those functions, you're making fairly arbitrary choices about which symbol to use, and those two are familiar. Most other syntax is really quite different: * variable definition has a completely different order to it with (optional) type ascription * function definition has some aspects of C++ (<> for types in generic functions) but much else is different - e.g. position of return type, where clauses, the 'fn' keyword, type ascription

ohazi 7y ago

I don't think I'd describe Rust's syntax as C-like. What gives you that impression? The only resemblance I see is curly braces. Rust doesn't even have a C-style for loop. If anything, Rust's syntax can be confusing because the order of names and types are reversed compared to C. This is a trend that a lot of recent languages are returning to because it can simplify the parser. Also backtick lifetime parameters, but that's a feature that no other mainstream language has, so it was bound to be a little confusing regardless of the syntax.

gattr 7y ago
To be precise: lifetimes are denoted by an apostrophe. (Backtick can be used in comments for Markdown formatting.)
Myrmornis 7y ago
I would certainly describe Rust's syntax as being in the family of C-like syntaxes. Function calls use function named followed by positional args in smooth parens, curly braces for blocks, & and * for pointers/references, if/continue/break/while, semicolon termination, square bracket indexing of array/vec, etc etc. It's very obviously a descendent of the C syntax family. Of course it has several critical extensions related to impl, generics, lifetimes, references, modules etc, partly influenced by C++ (e.g. generics syntax), Ruby (closure) and Python (self). It depends on your perspective, but if the scope is all programming languages, then Rust is syntactically very close to C.

kjeetgill 7y ago

Which syntax do you prefer? Lisp or python or php styles? That is pretty much your answer: It's subjective. Off the top of my head, I'd imagine that familiarity for the huge pool of C/C++/Java/C# programmers was probably a huge push for the chosen syntax.

jcranmer 7y ago

For most programmers, a C-ish syntax is going to be most familiar. In general, I'd define the "universal C-ish syntax" as: * Ending statements with ; * {} for braces, lowercase keywords for control flow * [] and 0-based indexing for arrays * Infix operator notation, with mathematical operator precedence * &, |, ^, ~ for bitwise operators * . is used for member access But they didn't copy all of C's syntax: * There's no ->, since dereference is usually automatic. * No ?:, if/else can be used as expressions instead * No ~, since ! on an integer variable does bitwise negation instead. * Pointer, array, and function types don't have the weird syntax they do in C... you say [ * mut fn()->i32; 4] instead of int ( * ())[4] * Types follow variables instead of precede them (x: i32 instead of int x) * No C-style casts (x as i32 instead of (int)x)

dragonwriter 7y ago
> There's no ->, Well, there is, but it's more like ML’s -> than C’s ->.
gjm11 7y ago
I was going to make a snarky comment to the effect that the Rust syntax for an array of pointers to functions isn't obviously less weird than the C syntax -- I assume the basic thing there is [<type>; <size>] -- but then I noticed that the C syntax above was very wrong, and the correct syntax is weirder :-). So what it should actually be is int ( * [4])(). The principle is that "declaration mimics use" and that a type is written like a declaration with the variable name omitted. So, for an array of pointers to functions mapping no-args to int: If f is such a function, you would call it as f() and get an int, so the declaration would look like int f() and the type would be int () except that functions, as opposed to function pointers, aren't first-class objects in C and don't have a type. If pf is a pointer to such a function, you would need ( * pf) instead of f, so the declaration would be int ( * pf)() and the type would be int ( * )(). If apf is an array of those, then you would need to replace pf with apf[something], so the declaration would be int ( * apf[4])() and the type would be int ( * [4])(). Which is, indeed, a bit weird. (Note: Spaces around all the asterisks because that seems to be the least-bad way of making HN not interpret them as markup. It's quite impressive how damaging HN's markup feature manages to be given how little it's capable of.)

mamcx 7y ago

Because audience. Sadly C/C++ dominate and that spread elsewhere. However "hard to read" is also the many concepts that rust have and certainly the combination of traits/lifetimes make some stuff very obtuse.

dragonwriter 7y ago

> Why did they stick to old C syntax? Did they? Rust always seems to me to a pretty free mix of C, Ruby-ish, and ML syntax (and an amazingly well chosen mix, because that description makes me want to run away from it, but the reality is pretty nice.)

Myrmornis 7y ago
I'm not really going to complain about syntax, but if I were... the only thing I don't like is the Ruby vertical bars around closure formal arguments. ES6 smooth parens and double arrows seem so much more fitting to a function to me. (I mostly write Python). I guess double arrows are used in match and single arrow in function return types, but if there had been a way to use arrows for closures I'd have voted for that.