Hacker News Reader

Comment by sleepysysadmin | Hacker News Reader

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.

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)

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.)

Good lord, you're right. I constructed the C syntax off the top of my head, and I knew about the declaration-mimics-use, so I started constructing it as if I would use it... I just somehow mixed up the [4] and the ().

C's function pointer and array syntax does make sense when you understand it, but even for experts, it can be difficult to get it right on the first go.

> There's no ->,

Well, there is, but it's more like ML’s -> than C’s ->.

“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.

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.

> 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.)

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.

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

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.

To be precise: lifetimes are denoted by an apostrophe. (Backtick can be used in comments for Markdown formatting.)

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.

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.

Reply on news.ycombinator.com