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

51–60 of 93 posts

Re: A taste of Rust

#51

Post by stesch »

lobster_johnson wrote: post #40
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 t…

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

Re: A taste of Rust

#52

Post by jes5199 »

dkarl wrote: post #46
jes5199 wrote: post #45

Earlier quoted context omitted.

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.

It's phrased as if he's talking about a different topic, but actually he's talking about the same topic.

Re: A taste of Rust

#53

Post by lmkg »

kibwen wrote: post #17
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-... )…

Indeed, there's been some discussion regarding forcing users to specify what sort of unsafety they desire when using unsafe blocks. There's no syntax whatsoever yet, but consider something like the following: unsafe(no-bounds-checks) { ... } or: unsafe(raw-pointers) { ... } Right now the problem is that once you drop into an unsafe block, everything that is unsafe becomes allowed. Obviously this is bad for correctnes…

It seems to me one of the prime difficulties with trying to differentiate types of unsafe behavior, is that often one will imply another. I recall that in C#, there is only one type of Unsafe block and the only unsafe operations it allows is raw pointer manipulation, but since you could theoretically point into the runtime itself, the set of implied consequences of Unsafe blocks is effectively unbounded. If Rust manages to drop its runtime it's not quite so easily susceptible, but even so, returning a pointer to a vtable outside of the unsafe block implies return-oriented programming implies unbounded capabilities.

I guess part of the issue is, what is the goal of marking code as unsafe? The use-case that C# was trying to serve was that you could be consuming a third-party assembly without access to source, and you want to know what are the possible consequences of running it. If Rust's main goal is being able to audit your own code for safety (either by hand or by tools), rather than trusting external binaries, then it makes more sense to take a feature-oriented approach rather than a consequence-oriented one.

Rust's pointer taxonomy might also help with providing degrees of consequences. You could, for example, restrict that raw pointers could only be cast to pointers with non-sendable kind, which would let you circumvent type safety while still controlling the scope of possible data races. Restricting lifetimes might be useful too, but that's too far beyond the limits of my experience.

Re: A taste of Rust

#54

Post by dom96 »

lobster_johnson wrote: post #42
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.

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

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

Re: A taste of Rust

#55

Post by steveklabnik »

Dewie wrote: post #50
steveklabnik wrote: post #47

Earlier quoted context omitted.

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.

Re: A taste of Rust

#56

Post by ww520 »

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

Re: A taste of Rust

#57

Post by pcwalton »

lmkg wrote: post #53
kibwen wrote: post #17

Earlier quoted context omitted.

Indeed, there's been some discussion regarding forcing users to specify what sort of unsafety they desire when using unsafe blocks. There's no syntax whatsoever yet, but consider something like the following: unsafe(no-bounds-checks) { ... } or: unsafe(raw-pointers) { ... } Right now the problem is that once you drop into an unsafe block, everything that is unsafe becomes allowed. Obviously this is bad for correctnes…

It seems to me one of the prime difficulties with trying to differentiate types of unsafe behavior, is that often one will imply another. I recall that in C#, there is only one type of Unsafe block and the only unsafe operations it allows is raw pointer manipulation, but since you could theoretically point into the runtime itself, the set of implied consequences of Unsafe blocks is effectively unbounded. If Rust mana…

> I guess part of the issue is, what is the goal of marking code as unsafe?

Basically, it's a way to be able to find the unsafe code by grepping for it. It's a mechanism for security auditors to be able to search for the unsafe code and audit it.

It also serves as some social pressure to avoid unsafe code.

Re: A taste of Rust

#58

Post by lightcatcher »

lobster_johnson wrote: post #40
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 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/

Re: A taste of Rust

#59

Post by ww520 »

I actually like Rust's compartmentalized approach to memory allocation. Having task/thread specific heap is very concurrent friendly, great for running programs in multi-processor system.

Re: A taste of Rust

#60

Post by lobster_johnson »

lightcatcher wrote: post #58
lobster_johnson wrote: post #40

Earlier quoted context omitted.

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