Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A taste of Rust

lwn.net

Post reply on HN
Print view View original

41–50 of 93 posts

Re: A taste of Rust

#41

Post by lobster_johnson »

jboy wrote: post #31
zepolud wrote: post #28

Earlier quoted context omitted.

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…

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…

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.

Re: A taste of Rust

#42

Post by lobster_johnson »

pcwalton wrote: post #37
zepolud wrote: post #10

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,…

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.

Re: A taste of Rust

#43

Post by Dewie »

pcwalton wrote: post #37
zepolud wrote: post #10

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,…

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.

What about making it optional, like in Haskell?

Re: A taste of Rust

#44

Post by lobster_johnson »

alcuadrado wrote: post #18
zepolud wrote: post #10

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,…

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 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 Of course, Ruby requires "end" for a lot of constructs, but it could have just as well have used braces.

Re: A taste of Rust

#45

Post by jes5199 »

maxcan wrote: post #38
maxcan wrote: post #36

Earlier quoted context omitted.

The better Haskell analog are the unsafePerformIO and related functions which match up pretty closely with unsafe in rust.

can someone explain why this (of all the flamebaity/controversial comments I make) is getting downvoted?

Okay, since you asked: Your comment doesn't make sense.

The parent comment: "rust unsafe and haskell unsafePerformIO are different!"

Your comment: "You forgot about unsafePerformIO! It's the same as rust unsafe!"

Re: A taste of Rust

#46

Post by dkarl »

jes5199 wrote: post #45
maxcan wrote: post #38

Earlier quoted context omitted.

can someone explain why this (of all the flamebaity/controversial comments I make) is getting downvoted?

Okay, since you asked: Your comment doesn't make sense. The parent comment: "rust unsafe and haskell unsafePerformIO are different!" Your comment: "You forgot about unsafePerformIO! It's the same as rust unsafe!"

Saying something different doesn't imply disagreement. He's just adding information.

Re: A taste of Rust

#47

Post by steveklabnik »

Dewie wrote: post #43
pcwalton wrote: post #37

Earlier quoted context omitted.

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.

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

Re: A taste of Rust

#48

Post by steveklabnik »

jboy wrote: post #35
zepolud wrote: post #10

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,…

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 communi…

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

Re: A taste of Rust

#49

Post by Locke1689 »

In contrast to this, array (or, as Rust calls them, "vector") references do not require the compiler to know that the index is in range before that index is dereferenced. It would presumably be possible to use the type system to ensure that indexes are in range in many cases, and to require explicit tests for cases where the type system cannot be sure — similar to the approach taken for pointers.

Thus, while it is impossible to get a runtime error for a NULL pointer dereference, it is quite possible to get a runtime error for an array bounds error. It is not clear whether this is a deliberate omission, or whether it is something that might be changed later.

I presume that's because the Rust designers didn't want to include a dependent type system. Comments from pcwalton?

Re: A taste of Rust

#50

Post by Dewie »

steveklabnik wrote: post #47
Dewie wrote: post #43

Earlier quoted context omitted.

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?
Post reply on HN