Hacker News Reader

Comment by zepolud | Hacker News Reader

It might be childish but I just can't force myself to swallow the ugly curly braces and semicolons.

Some compromises had to be made, e.g. the lack of tailcalls is a regrettable but nonetheless well justified decision. But why didn't they include a standard indentation style in the language specification itself and get rid of the cruft? They have one for Servo anyway, which is the raison d'etre of the whole language, so it's bewildering to me why it isn't included as a part of the specification.

It just pains me to see a promising new language being burdened with an ugly looking syntax when the language itself is quite elegant.

View on HN

The use of semicolons and braces was a decision made in the early days to make C++ programmers feel more at home. There are really good arguments both for and against whitespace-oriented syntax. (I actually prefer whitespace-oriented syntax, although I can see the arguments on the other side!) But we had to pick one and disappoint somebody.

I wonder how much surveying you guys did?

As a sometime C++ dev, I fully recognize the utter inanity and burden of typing semicolons where the compiler should know perfectly my intent, and would rejoice in a language that did away with them. In fact, it's one of the features of Go that I really like. Rust's syntax, on the other hand, feels like a step backwards in some ways.

I wrote a bit more here: https://news.ycombinator.com/item?id=5608157.

You should checkout the Nimrod programming language which has a syntax similar to Python, i.e. it gets rid of the semicolons and braces.

I personally like semicolons. It's similar in spirit to the period of English. Even languages which didn't traditionally have the period have adopted it in the last couple of centuries.

More practically, it seems to remove a class of errors. Semicolons are optional in Javascript and I've seen posts here about subtle errors that can creep in when you change code a little carelessly.

And even more practically, it allows you to type "one liners" into things like REPLs even if they aren't one liners.

Just my two cents.

The period is necessary in human languages because we write sentences next to each other and we need some way to separate them. Programming languages are line-based and are more akin to recipes or poetry. So that's a bad analogy. Unless you consistently write all your statements on a single line, of course.

Furthermore, you present a false dichotomy here. A semicolon-free language can easily have semicolons as an optional measure if you do want to cram several statements together on the same line. You mention one-liners; a semicolon-free language can support semicolons. Here's a Ruby one-liner:

    >> b = Box.find(3); t = Thing.new; b.add_thing(t)

A class of errors: Well, anecdotally, I have personally never had a single issue with semicolons in JavaScript in all my years developing with it, simply because I always use semicolons. The reason is that JavaScript has a bunch of "semicolon insertion" rules that are not well understood, so dropping the semicolons is a bad idea, as the recent "fiasco" showed, and I just decided very early on not to go that route.

As I understand it, JS is a semicolon-enforced language that allows you to drop them at your convenience, whereas Ruby, for example, is a semicolon-free language that allows you to include them at your convenience. I'm not a parser expert, and I won't swear there is a significant difference except in which rules are defined. But I do know that semicolons are categorically not an issue in Ruby. So I would say that this argument is invalid, too, because it presents a flawed language as the ideal. The Rust guys should not need to base their design on JavaScript.

I've on a few occasions had problems with semicolons in Java: accidently putting a semicolong like this:

if (something()); { somethingOther(); }

The semicolon seemed to shortcut the whole if-block. I don't know why that thing is even allowed by the compiler.

Being able to write if and while loops with am empty body is due to braces being optional if you only have one statement and due to the empty statement being a legal statement (doing so keepsthings simpler).

As for the second {}, its to allow you to create inner scopes where you can declare variables with a more restricted scope without needing to do something silly like "if(true)".

Empty block statements are OK sometimes with while and for loops when the real action that matters is in the condition:

    while(!trySomething()){} //empty body for the loop

And since these language

This error can't happen in Rust. If blocks must be braced.

The semicolon following the conditional is an empty statement; it ends the if statement equivalently to "if (something()) { }". It's not often seen, but sometimes can be found in:

     for (i = 0; a[i] != x; i++) ;

to find the first index equaling x.

Personally, I always use braces in conditional and loop statements, so I'll never have the empty statement semicolon. But that's me.

> Personally, I always use braces in conditional and loop statements, so I'll never have the empty statement semicolon. But that's me.

But if you have

if (something()); { somethingOther(); }

Then you have a new problem: you intended the braced statement to execute iff the if-statement evaluated to true. But since you put the semicolon after if by accident, now the braced part will execute no matter what the if-condition evaluates to.

(my point was about unintentional use of semicolon after if-statement - in which case always using braces doesn't seem to help.)

What about making it optional, like in Haskell?

Currently, lines with and without semicolons have different semantics, so that doesn't work.

> Basically, ending an expression in Rust with a semicolon ignores the value of that expression. This is kinda weird. I don't know how I feel about it. But it is something you should know about.

http://www.rustforrubyists.com/book/chapter-06.html

You could still make braces optional though, right?

You could do whatever you want. The idea is that `rustc --pretty` reformats code, so you could make the input flexible enough to be whatever you want, really. Or write your own transpiler.

>It might be childish but I just can't force myself to swallow the ugly curly braces and semicolons.

Yes, it's childish. Worse, it's bikeshedding.

I think it's reasonable to complain and openly discuss comparatively minor issues when a language hasn't even reached 1.0, since it's at that point a prime time to iron out everything that might be an annoyance later.

Defining a sane syntax while the language is still in its infancy is anything but bikeshedding. You have only one chance to do it right before an entrenched codebase develops or interest in the language fizzles.

MS Research did this right with the experimental hardwhite support while F# was still in alpha. People liked it so much that it became the default style for the compiler and the standard library. It would be impossible to try to make the switch now that the language is widely used.

It might be childish for me to choose one language for a project than another over trivial things like semicolons, but for the language itself it's an irreversible decision once the spec gets set in stone.

To me, one of the most interesting design decisions of Rust is that the creators strongly try to avoid inventing new language features. Instead, they attempt to find the best combination of tried-and-true existing features from a variety of other languages.

I wonder whether language syntax could be considered such a "feature" -- that is, the Rust creators would consciously prefer to combine existing syntaxes (at this point, mainly C++, Haskell, OCaml and Ruby) than invent their own.

An argument could be made that they could just "use Python's syntax", but perhaps a counter-argument would be that Python's syntax would need to be extended so much (for types, pointers, templates, etc.) that the result would effectively be a new invention.

That logic sounds fishy to me. After all, they took C++'s semicolon syntax over Haskell, OCaml and Ruby's semicolon-free syntax, so there must have been a reason for picking one over the others. So the issue is not about inventing syntax, it's about choosing one (existing) syntax over another.

pcwalton says it was to attract C++ devs, which is interesting considering that Go was also designed to attract C++ devs and made the opposite choice. As a sometime C++ dev, I recognize the historical uselessness of semicolons and would love a replacement language that did away with them.

Since when OCaml is semicolon-free? It not only has semicolons, single semicolon (;) means something different than double semicolon (;;). The former is used as an expression separator, like comma in Erlang, and the latter denotes the end of a top-level declaration, like period in Erlang. That's a pain while refactoring, but I can live with it. Anyway, that's just a style, nothing more, you can learn to love it or you can write a "transpiler", it's really a non-issue.

True, Ocaml has semicolons, although it's a little different given that you can construct deeply nested functional expressions without ever using a single one. If I remember correctly the semicolon is a separator, not a terminator, which means that declarations don't need to end with a semicolon, for example, and you pretty much only need it to separate statements.

AFAICT, if you were to write in Lisp-like purely-functional style, you wouldn't need any semicolons in your Rust code either.

I'm not sure I prefer 'in' over semicolon in declarations. I mean:

    let x = ref 0 in
    (* something *)

in Ocaml is not much worse/better than

    let mut x = 0;
    // something

in Rust. As I said above, that's really a minor, stylistic issue, one probably would write "let x = mut 0 in" for a week or so (coming from OCaml) and that's it, after a week it becomes as natural to write semicolon as it is to write 'in'.

I agree, I didn't really put OCaml forward as the ideal solution. Ruby and Go solve the semicolon problem in much better ways, in my opinion.

No, it's actually the opposite of childish: being able to digest new things is exactly what children do and exactly what adults do less.

I think it would be an exceedingly interesting project to define a Pythonic syntax for Rust, then implement a Cfront-like frontend to translate Pythonic-Rust to brace-and-semicolon Rust before compiling it. (The Rust language spec is gradually reaching a point where there would presumably not be large, disruptive changes.)

You could make it available to the Rust community (and even the broader Rust-interested community on HN and Reddit) and see if it takes off.

If the Python-Rust were to become more popular than brace-and-semicolon Rust, the creators may well be persuaded to adopt it. Or at the very least, you'd have a thriving like-minded Python-Rust community. :)

There already is `rustc --pretty`, but it has some bugs and such. I'm sure you could modify it for that purpose.

Python indentantion-as-block definition has many drawbacks, not to mention the lack of semicolons that forces \

you \

to \

write \

so \

many \

backslashes.

They are not the ultimate solution for block definition and line breaking. You must be very used to them, and that's why you find the lack of it irritating, but that's another story.

Disclaimer: I code python every day of my life nowadays, I'm not a python hater.

I've written a lot of Python too. When I need to span lines, usually there's an easy way to use parens to do

    blahblah = long().invocation_of.something(with,
                   lots, of, parameters)

which is generally more idiomatic. (Of course one wishes to avoid long lines at all but that's not always possible.)

I found that parnes rule used as an awful hack a lot of times. I use it only when the parens are naturally placed, but there are people that just add two parens to avoid one backslash... completely insane!

How is the backslash better? The parantheses can stay if you join two lines or split them.

Yup, and parens also allow comments.

I type many, many more semicolons in C or C++ than I type line-continuation backslashes in Python, so I prefer the option that requires fewer keypresses and less syntactic noise.

Or to put it another way, I'd much rather have to syntactically announce a line-continuation (which happens rarely, and is thus an atypical event that is worthy of note) than announce the end of a statement (which happens every single statement, and is thus to me much less worthy of note).

My reasons for preferring indentation-as-block over brace block-delimiters are similar: The indentation is a much more subtle, unobtrusive, un-noisy alternative to braces.

Furthermore, when I code in C or C++, I indent (and brace-delimit) everything properly, according to a style guide; so if I'd be indenting the block anyway, why not make the indentation syntactically meaningful, to save me some keypresses and slightly decrease the syntactic noise?

Plus, for bonus points, brace-less blocks mean I never need to play the brace-matching game. ("Have I got an extra/missing brace in there somewhere? Put the cursor on the brace and tap `%` until I work out what's out of place." True, it doesn't happen frequently if you keep your blocks and functions small, but I'm quite happy to avoid it altogether.)

I prefer Ruby's approach, which is not whitespace-sensitive, but has a very liberal approach to where expressions end.

The general rule is, as with Python and Go, that open braces, brackets, parens or quotes have precedence; and operators or punctuation at the end of a line will continue to the next line.

In addition, there are some complicated parsing internals -- not just for expression-ending sensing, but also for supporting parens-less method calls -- that endow the parser with some compiler knowledge about what tokens are variables and what tokens are methods. In other words, the parser has information that violates the parser/compiler separation of concerns, but it works really well in practice.

The only time I ever use \ in Ruby is for string literals that need to be broken up for readability:

    my_string = "This is a very long string that" \
      " must be wrapped."

You can use + or <<, but this will be evaluated at runtime, whereas \ results in a single string allocation.

Of course, Ruby requires "end" for a lot of constructs, but it could have just as well have used braces.

Ruby can use braces instead of end, both are valid.

Hm? Only for blocks. Not classes, methods, if/unless, while or begin/rescue.

Dang, you're right, I could swear otherwise but yup, just on blocks.

if you put a backslash on every line in Python, check your code, variable names. I rely more on splitting on tuples or dictionary items. So you can actually write like this:

    (forces,
     you,
     to,
      ...
     )

I can accept the braces, but the semicolons were a big letdown for me. We should have learned by now from successful languages that the semicolons is obsolete.

If Ruby can do it (and Ruby does it very well with just a few simple rules, even though its lexer admittedly contains parsing logic to deal with the challenge), then Rust can do it.

The other disappointing aspect of Rust is the "line noise" problem. Rust has three types of pointers, and needs a line-noise character for each of them. That, combined with the liberal use of underscore-based identifier names, makes it very noisy. (Ruby also uses underscore-based names, but the relative absence of noise characters keeps it clean.)

In my opinion any new language project ought to have an overriding aesthetics process. Aesthetics is often belittled (as you say, "childish"), but code readability, over time, becomes more important than almost everything else.

I like Rust's design principles, but Go definitely wins the syntax competition for me.

The characters for the different pointer types remind me a little bit of the Hungarian notation. And I thought this is a bad idea.

It's not Hungarian notation, the sigils are part of the type. Here's how you'd say the same thing in Rust and C++:

  Rust: ~T
  C++: unique_ptr<T>

Are you aware that the semicolon is meaningful in Rust because it indicates returning from a block (as well as separating expressions). mitsuhiko (author of Python's flask, jinja2, etc) wrote about why he loves Rust's semicolons: http://lucumr.pocoo.org/2012/10/18/such-a-little-thing/

Yes. And I really dislike that there is a difference. The semicolon is so small and what the block returns is so important, it's a really weird thing to love.

Since I am being downvoted for expressing a technical criticism, let me clarify:

I like explicitness, readability and clear, unambiguous syntax. Two small dots at the end of a line completely changing the entire block's meaning is, to me, a violation of those principles.

My own immediate reaction upon first reading the Rust tutorial was that significant semicolons were completely brain-dead. However, time went on and I was never able to think of a scenario where the compiler wouldn't immediately detect an errant or missing semicolon. Nowadays I completely adore them (though I still recommend that people use an explicit `return` in any expression of nontrivial length).

> Rust has three types of pointers, and needs a line-noise character for each of them.

`~T` and `@T` were felt to be preferable to `std::unique_ptr<T>` and `std::shared_ptr<T>`. You really do type them all the time.

I understand that. That's not the alternative I want.

Go actually gets by with just one type of pointer syntax. Go is what a colleague calls "being stupid simple", which is really its strongest asset at this point. It eschews a lot of complexity by not trying to be clever.

The problem with Go's pointers is that no thought has gone into thinking about goroutines as boundaries of data ownership. It's simple to share mutable data between goroutines, and it's impossible to verify (manually or by any kind of analysis) that a program is not a shared-everything pile of spaghetti. This, plus mutable data, makes it impossible to safely implement things like Erlang-style remote task spawning.

What I would like in my ideal language is a single pointer type: A pointer into the task heap. However, pointers may only be shared between tasks by copying or by transfering ownership, except for immutable data, which can be shared freely with no overhead other than normal GC/refcounting. With some COW magic you could even make the copying really fast, too. Then all you need is a simple syntax for limited references that cannot be stored, only copied, so that you can actually have functions that work on data efficiently without leaking their pointers anywhere.

Maybe I am being naive -- I won't pretend to be a Rust expert. But this model works pretty well for Erlang. I find that while Rust is clever, it falls into the other extreme and becomes too clever; and being too clever is a kind of stupidity. For example, borrowed pointers sound neat on paper, but then you find you have to dick around with declaring pointer lifetimes. That's pretty insane. It results in a kind of syntax that represents everything I hate C++ for. I can understand that it took a while to decide on a syntax for declaring lifetimes. It looks totally weird and arbitrary. (Quotes are for strings, man!)

It's also possible that Rust just is not for me. :-)

I would also like it if we could just copy everything, but for implementing a competitive browser this gets really hard really fast. Erlang's actors are not really designed to squeeze every cycle out of the hardware. Incidentally, you can get this model with Rust's `flatpipes` module, which allows you to send data across Rust.

We experimented with COW designs in the early days. It seemed pretty hard to implement: hardware MMUs operate on page granularity, not on object granularity, so you need (thread-safe!) guards for all objects. That's pretty tough from a performance point of view. Perhaps it can be done, but it seemed less risky to just use uniqueness.

Indeed, the types of programs I write are very different from a web browser.

For what it's worth, I know I speak for at least a couple of other people when I say that we were, for a long time, hoping for a "better Go" -- we are mainly rubyists who want native compilation, a better/safer type system, better concurrent performance, more easily massively parallelizable -- and that Rust's development has been going in a slightly different direction than we were hoping. Perhaps it's time to re-evaluate C++11 or even Haskell.

Aside from the native compilation bit, could Elixir be the language that you're really looking for?

http://elixir-lang.org/

Speaking personally for a moment here, I'm a Python/Javascript/PHP dev by day, and the reason that I'm interested in Rust is precisely because of all the new concepts that it's forced me to learn. I could never get into C because I enjoy having two feet, and I could never get into C++ because I know that there's no escape from that stygian pit. For me, Rust is precisely the right balance of low-level/safety/coherence, semicolons be damned.

Elixir is neat, but it's such a leaky abstraction; you still have to deal with a lot of Erlang stuff that Elixir doesn't cover.

Also, Erlang is slow. Really really slow. It's faster than Ruby, I think, but not much. And It sucks at a lot of things that should be fast in a functional language, such as file I/O.

Erlang itself is also neat, but the syntax is abhorrent (commas and periods instead of semicolons!), performance is awful, and the language has many warts (no Unicode, no structs, etc.).

I see where you're coming from. As for me, I am intimately familiar with everything that Rust provides, and it's frustrating because it's close to what I have been waiting for, but it makes a bunch of design choices I disagree with. Same with Go.

For now, Go is much closer to what I want than Rust, but performance is pretty awful for many things, so I'm not a happy clam.

> Really really slow.

If the goal is simulate n-body problems and solve one instance of sudoku it is not the right tool. If one needs a fault tolerant system to maintain 2M concurrent connections to clients then it is the best tool for the job.

http://www.erlang-factory.com/upload/presentations/558/efsf2...

Think about Erlang as a tank. A cool hipster comes to you says "LOL, my fixie bicycle is sooo much faster than your tank" and he's right because in some cases you just want to go to the nearest coffee shop to pick up an espresso. However a time comes when you need to go into battle and putting a turret and shields on the bike only works so far, then it is time for a serious tool for the job.

> performance is awful

I don't know I wouldn't call something that can handle millions of concurrent connections slow. It is slow if you all you need to do is handle a single connection at a time.

Fault tolerance is actually the main feature of Erlang everything else flows from it. You don't always need it but when you do need it there is nothing like it. Fault tolerance mean paying some performance penalty.

> syntax is abhorrent (commas and periods instead of semicolons!),

Don't those make more sense though? How does a semicolon ending a statement make more sense than a period. And if there are 3 things that are executed then comma seems quite natural as well. On the other hand few languages rival Erlang's pattern matching.

> no structs

Frames/Maps are coming next year as part of R17

Erlang is great, but for me, its problems simply outweigh its benefits.

For example, not every app has a need for Erlang's massive parallelism. I can't write desktop or iOS apps in Erlang. Small utility scripts are cumbersome. There seems to be no kind of strong graphics or game support for it. For web apps the lackluster performance means is not really a step up from Ruby, which I currently use, so in that area there is no reason for me to switch.

In fact, the only area where Erlang is really perfectly suitable is in developing fault-tolerant, concurrent, parallel, distributed systems. And yet when I do need to write such a system, I look to Go instead.

> Don't those [commas and periods] make more sense though?

No, they really are a bad choice. First, any kind of statement terminator/separator should be unnecessary, as I have argued elsewhere. Secondly, distinguishing between two types of terminators is a bad idea because it makes editing harder. If I have

    A,
    B.

and I want to switch the order to:

    B,
    A.

then I can't just use my editor's nifty line-transposing mechanism. I have to edit each line and change the "," into a "." and vice versa. It's incredibly badly thought out.

Really, I like Erlang, but whenever its syntax is discussed, its defenders come out of the woodwork to make arguments without ever really wanting to listen. Syntax does matter. From speaking to lots of people, I know that Erlang's antique and cantankerous syntax is the number one problem preventing people from adopting it. As long as erlangers do nothing about their syntax, it will remain a weird little language that people admire but don't use.

Just look at Elixir -- people actually get excited about it. Because it has a nice syntax.

> few languages rival Erlang's pattern matching

Erlang's pattern matching is cool, but its reliance on ordered lists (which it calls tuples even though the fields are unnamed) makes it less cool again. I vastly prefer Haskell's pattern matching and overall approach to typing.

I think the syntax decision is a good one. Indentation-based structure is nice, however in some cases it can cause some pains: code generation or embedding code in a document are two common examples. As for requiring semi-colons, I don't really mind them; in fact, I'm less annoyed at having to type semi-colons than having to remember rules for auto-insertion or semi-colons.

Haskell solves this problem by allowing both. In any situation where layout/indentation has meaning, braces and semicolons may be substituted.

I found the braces and semicolons easy to work with and make reading code much easier. The line continuation (\) in other languages make it ugly.

Complaining about braces and semicolon is like complaining about parenthesis in LISP. Learn to appreciate the strength of a language and move beyond its syntax.

The standard indentation style is four spaces. Rust does have a pretty-printer (think gofmt), but it's not very good right now so it never actually gets used. It's very old and basically needs to be entirely rewritten.

Reply on news.ycombinator.com