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

31–40 of 93 posts

Re: A taste of Rust

#31

Post by jboy »

zepolud wrote: post #28
coldtea wrote: post #21

Earlier quoted context omitted.

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

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

Re: A taste of Rust

#32

Post by kzrdude »

alcuadrado wrote: post #24
jerf wrote: post #22

Earlier quoted context omitted.

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.

Re: A taste of Rust

#33

Post by [deleted] »

coldtea wrote: post #21
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,…

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

[deleted]

Re: A taste of Rust

#34

Post by chongli »

gnuvince wrote: post #23
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 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.

Re: A taste of Rust

#35

Post by jboy »

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

Re: A taste of Rust

#36

Post by maxcan »

monkeyfacebag wrote: post #4

The article doesn't specify what exactly, is permitted by an unsafe vs. safe function. The Rust reference indicates the additional operations permitted by unsafe functions are: 1. Dereferencing a raw pointer. 2. Casting a raw pointer to a safe pointer type. 3. Calling an unsafe function. I was expecting something more along the lines of Safe Haskell ( http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-... )…

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

Re: A taste of Rust

#37

Post by pcwalton »

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.

Re: A taste of Rust

#38

Post by maxcan »

maxcan wrote: post #36
monkeyfacebag wrote: post #4

The article doesn't specify what exactly, is permitted by an unsafe vs. safe function. The Rust reference indicates the additional operations permitted by unsafe functions are: 1. Dereferencing a raw pointer. 2. Casting a raw pointer to a safe pointer type. 3. Calling an unsafe function. I was expecting something more along the lines of Safe Haskell ( http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-... )…

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?

Re: A taste of Rust

#39

Post by loqi »

kzrdude wrote: post #32
alcuadrado wrote: post #24

Earlier quoted context omitted.

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.

Re: A taste of Rust

#40

Post by lobster_johnson »

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

Post reply on HN