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

21–30 of 93 posts

Re: A taste of Rust

#21

Post by coldtea »

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.

Re: A taste of Rust

#22

Post by jerf »

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

Re: A taste of Rust

#23

Post by gnuvince »

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.

Re: A taste of Rust

#24

Post by alcuadrado »

jerf wrote: post #22
alcuadrado wrote: post #18

Earlier quoted context omitted.

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!

Re: A taste of Rust

#25

Post by jboy »

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

Re: A taste of Rust

#26

Post by prg318 »

FreezerburnV wrote: post #12
MaxSize wrote: post #8

Earlier quoted context omitted.

> Also, is anyone using Rust in non-toy projects? Since it's not production ready yet: no

You should double-check what kind of projects are being worked on before saying that it isn't being used for non-toy projects :) I can list at least two off the top of my head: Q^3, which can render Quake 3 maps and will eventually be its own game: https://github.com/Jeaye/q3 Servo, an experimental web browser being written by Mozilla: https://github.com/mozilla/servo

There is also a Famicom/NES emulator written in rust: https://github.com/pcwalton/sprocketnes

Re: A taste of Rust

#27

Post by Dewie »

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.

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.

Re: A taste of Rust

#28

Post by zepolud »

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.

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.

Re: A taste of Rust

#29

Post by pnathan »

MaxSize wrote: post #13
FreezerburnV wrote: post #12

Earlier quoted context omitted.

You should double-check what kind of projects are being worked on before saying that it isn't being used for non-toy projects :) I can list at least two off the top of my head: Q^3, which can render Quake 3 maps and will eventually be its own game: https://github.com/Jeaye/q3 Servo, an experimental web browser being written by Mozilla: https://github.com/mozilla/servo

For me, a non-toy project is a project that runs in production, where I can build my business on.

Rust isn't there yet in my opinion. The syntax and semantics are still undergoing development, and the standard library is still in the process of definition.

If you want to rewrite your codebase on a quarterly to cope with the changes, that's up to you, but I wouldn't.

I'm waiting for 1.0 to really start writing code in it.

Re: A taste of Rust

#30

Post by pjmlp »

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

Usually strong typed languages for systems programming use the unsafe concept for the usual dirty tricks of low level programming that question language's safety.

You can find this in Ada, Modula-{2,3}, D, Oberon and many others.

Post reply on HN