Hacker News Reader

> This is like optimising for the least readable code possible. I imagine it's going to be a nightmare in practise.

We've written hundreds of thousands of lines of Rust and this has never been an issue. The typechecker will catch any misuses of semicolons.

> What I do care about is being able to tell exactly what some code does by glancing at it, without worrying too much about whether someone wrote = instead of ==.

The typechecker will catch misuses of = versus == as well. So assuming that the code you're looking at passes the typechecker, you don't have to mentally distinguish between = and ==.

> However for now, I much prefer the KISS approach taken by Go, in spite of a couple of things missing from the language (that will probably get there in the end).

They're different languages. Go does not have memory safety without garbage collection, and will never have it while remaining backwards compatible. But that was an explicit design goal of Rust. That is why Rust has the lifetime and unique pointer support, which allows Rust to support safe low-level programming in a way that wasn't possible before.

I came from a primarily-Python background; that the last value in a block is the outcome of the expression seemed to me a gimmick when I first started writing Rust (just under a year ago)—I, as you appear to be doing, only saw it as relevant at the end of a function, thus saving only half a dozen letters. I quickly discovered that it is not a gimmick; the fact that it applies to any expression is marvellously useful in Rust code, with its everything-is-an-expression doctrine. (For a language like Python, without this orientation, it would be just a gimmick.)

That the last value in a block is the value of the expression is something that makes a lot of code much more readable, as it frequently obviates the need for additional temporary variables.

I was sceptical until I actually used it. Now I’m converted; though I still also like Python’s pure statement-oriented approach in various ways, I prefer Rust’s model.

I thought it was crazy at first, but `;` operator as a statement separator that returns `()`, and an implicit return at the end of a block greatly reduces the need for mutable temporaries and leads to a more functional code style. This is a real win when it comes to code maintenance. I greatly miss it when shifting back to other more statement-driven languages. I would encourage you to try it!

> This is like optimising for the least readable code possible. I imagine it's going to be a nightmare in practise.

I have pushed a reasonable amount of code to the rust repo, my own libraries, and some to servo, and it has never been an issue, in fact it has been the opposite (proof: https://www.ohloh.net/accounts/bjz and https://github.com/bjz/).

> What I do care about is being able to tell exactly what some code does by glancing at it, without worrying too much about whether someone wrote = instead of ==.

Rust solves this by having assignment expressions always returning `()` from assignment expressions and not having implicit conversions. The issues with `==` vs `=` completely vanish.

FWIW, I am a big fan of easy to read code (as I frequently need to read other people's code in order to 'audit' it). But like others have said, in real Rust code the ability to mix blocks and expressions does not seem particularly confusing to me, and is used in many places other than the end of a function, in more of a functional style. Here is a representative-ish example:

https://github.com/rust-lang/rust/blob/master/src/librustc/m...

Personally I think most other things in Rust (namespaces, constant as_slice() unwrap() etc.) are currently too verbose, although I'd say that also impedes readability.

librustc isn't a very good example of showing, since it's not idiomatic Rust and a mixture of previous iterations.

Hah, I would caution against looking into the depths of rustc for examples of good examples of rustic code. Many parts of the compiler have changed very little from the original bootstrapping from OCaml, and have only been incrementally updated since then. No doubt it will eventually be cleaned up, but it will be a big effort.

I do agree with the rest of your first paragraph though.

You should keep an open mind about this until you've written and read a reasonable amount of rust code. Rust isn't the easiest language to write or to grok-at-a-glance, but the semicolon thing is a real red herring. It's a really interesting decision, but it really isn't a big deal in practice. There are always other more at-a-glance clues that you either do or don't want a value.

> Developers always seem to be complaining about having to type this or that, when they should be much more concerned with what they have to read!

Or maybe they find terser syntax to be more readable. If verboseness was always more readable, if not necessarily more "writable", than terseness, then no one would have a problem with Java since it has good IDE support, including autocomplete and generation of boilerplate code. But it turns out that it's not just a matter of being lazy typists.

That is what's known as a straw man argument. Nobody said verbosity always improves readability, just that it's easy to get too terse, just as Java demonstrates it's possible to get too verbose.

I'm pretty comfortable writing complex regular expressions, but I don't know many other developers that are and I certainly don't like trying to grok anything longer than about 10-15 characters that I didn't write in the preceding 15 minutes. This is a perfect example of where terseness is fine for simple problems, but it does not scale.

I already mentioned Go because it has a pretty terse syntax, but one that is very carefully optimised for readability. One of the things the designers of Go are careful about is not adding too many operators, keywords, or usage rules to the language, which keeps everything nice and simple.

Rust OTOH seems to have a metric boatload of operators that work in different ways depending on the specific context. That's a recipe for a ton of cognitive load, which isn't helpful for writing code, but reading suffers even more.

I don't yet know enough about Rust to say whether this is as bad as operator overloading in C++. As I said, I will reserve judgement until 1.0 because it's entirely possible things will change drastically before then.

> Rust OTOH seems to have a metric boatload of operators that work in different ways depending on the specific context.

What operators does Rust have that Go does not? I believe Rust has no more operators than Go.

This is just my impression based on those tutorials I've looked at so far; I've decided to put off learning it properly until 1.0, whereas I know Go pretty well. IIRC, the move semantics and lifetime annotations were one area that stuck out as pretty heavy on context-specific operators.

Move semantics don't have operators; they happen automatically invisible. Lifetime annotations are not part of operators; they're part of types. The only operator is the same as in Go, &.

If anything Rust has been busy removing operators. As far as I can recall, move semantics have no operators at all (someone who remembers better can probably correct me on this), and lifetime annotations are just 'lifetime (I suppose you could consider ' an operator?). Rust is also LL(1), so it was a very explicit design decision to have as few context-specific operators as possible (indeed, a few suggestions for possibly more intuitive syntax have been decided against for this reason). So what you're saying really hasn't been my experience with Rust at all. In fact, the only really hard thing about Rust, from my perspective, is the semantics, not the syntax :)

Exactly why I'm reserving judgement for now.

> That is what's known as a straw man argument. Nobody said verbosity always improves readability,

You're right.

There is readable based on each character such as semicolons, dots or curly braces and there is readable based on the shape of code.

That is two separate levels. When you first glance a page of code the first time in 1 second, you should tell what the structure of the program is. How many blocks (for/while/if) it has. How many functions, how big they. You haven't yet had time to read each individual character. That is one level.

Here variable and ambiguous indentation rules get in the way. If there is non-uniform, non-standard indentation then you have to start reading individual lines in detail. If there is standard indentation then it doesn't even matter about little commas and semicolons, it is a level higher than that.

Then past that it is about individual functions, classes, modules, and what have you. Then it becomes about == vs = or . vs , and so on. If there is ambiguity there it could be harder. Like in Python I added a , at the end of a some variable. So that turns it into a tuple. And it resulted in a strange exception down the line. In C the = vs == is notorious. But there are others. None of this make the task impossible, but just slightly harder. The problem is that if this is done many many time over the course of a lifetime of a piece of code. Maybe it take 10 extra seconds for reader to understand the code, that multiplied by thousands of times will add up.

Simple/common ideas should require terse syntax. Complex/rare ideas should require verbose syntax.

Prefer "x = y + z" to "ADD y TO z GIVING x".

Prefer "[[NSThread alloc] initWithTarget:t selector:s object:o]" to "pthread_create(&p, &a, &f)".