Live data from Hacker News

A Week with Mozilla's Rust

relistan.com

81–90 of 104 posts

Re: A Week with Mozilla's Rust

#81
post #39

Earlier quoted context omitted.

> Also, does the compiler complain about my example above being not exhaustive? Yes, although the error message isn't very good: crypto.rs:55:23: 59:5 error: non-exhaustive patterns: true not covered crypto.rs:55 let computed_key = match (key.len() > self.block_size, key.len() self.zero_pad(self.hash(key).digest), crypto.rs:57 (false, true) => self.zero_pad(key), crypto.rs:58 (false, false) => key crypto.rs:59 }; err…

it should be expressed with conditionals anyway. match key.len() { k if k > self.block_size => .. k if k .. k => ... or even match key.cmp(self.block_size) { Equal => .. Greater => .. Less => ...

Absolutely.

Re: A Week with Mozilla's Rust

#82
post #72
post #45

Earlier quoted context omitted.

I'd prefer such code to actually be the part of compiler, simply, C headers directly readable by the compiler as soon as they are referenced from the code as C headers.

The only way to do this fully automatic is to integrate a partial C compiler, able to understand the pre-processor and all types of declarations.

There was/is a plan to use clang to help with this.

(In fact, rustc used to build clang as well as LLVM, but this was disabled since it wasn't being used (yet).)

Re: A Week with Mozilla's Rust

#83
post #22

Earlier quoted context omitted.

I've took a look on one "real" example, I admit I haven't spent much time with the language, I just want to get the idea looking at the code which really does something, I like that more than starting with boring tutorials: https://github.com/mozilla/rust/blob/master/src/libextra/jso... I know it's the least interesting thing, but for me the simplest rule to recognize Rust vs Go is that at the moment Go has the nice…

~str is mutable. error probably doesn't need a mutable string, though. either it's just an overlooked API (json is an old part of the codebase, doesn't really see a lot of attention) or what pcwalton said about calling something down the line.

~str isn't inherently mutable; it's an owned string, and so is mutable if placed in a mutable variable.

The reason it's used here is so that the error messages can be constructed at runtime e.g. `fmt!("line %u: trailing characters", line_number)`, if it was using &'static str (i.e. a compile-time literal) then one could only use hard-coded error messages.

Re: A Week with Mozilla's Rust

#84
I must say i am really surprised about the presented features of the language. It seems to take a lot of the nice things of more dynamic languages and puts them into a fast, compiled system language. I will have to try Rust, now!

Re: A Week with Mozilla's Rust

#85

Why do people keep reinventing syntax? Quick tell me what the following mean: struct Digest { digest: ~[u8] } // what's ~ here? for self.digest.iter().advance |&byte| { acc = acc.append(fmt!("%02x", byte as uint)); } acc What does the above mean? acc as a separate line and nothing else I hate it when people reinvent the same construct that can be found in other languages but differently. I guess they want to do somet…

just offhand, from my understanding, ~ signifies rust's pointer type. It's different from C's pointer type in subtle ways, so the symbol is different, to force reader to actually look into it, and understand what it does different instead of just assuming it's just like C's. There's also the advantage that there's no way to conflict with the * multiplication operator.

`~` is just one pointer type; there's & and * also built-in to the language (and @, but that's moving to the standard lib); and Rust provides the control required for implementing arbitrary "smart-pointers" (e.g. reference counting is a library pointer).

~ is an owned pointer (like unique_ptr in C++); & is a "reference" or borrowed pointer (allowing access to data without taking ownership); * is a raw/unsafe pointer, and is identical to C's pointers.

Also, the * pointer doesn't conflict with multiplication because they can never occur in an ambiguous context:

  foo * bar = NULL; // C

  let bar: *Foo = std::ptr::null(); // Rust

  let bar = std::ptr::null(); // Rust, using type inference

Re: A Week with Mozilla's Rust

#86
post #82
post #72

Earlier quoted context omitted.

The only way to do this fully automatic is to integrate a partial C compiler, able to understand the pre-processor and all types of declarations.

There was/is a plan to use clang to help with this. (In fact, rustc used to build clang as well as LLVM, but this was disabled since it wasn't being used (yet).)

This is the approach also taken by DStep for D.

https://github.com/jacob-carlborg/dstep

Re: A Week with Mozilla's Rust

#87
post #11

Of all the upcoming languages out there. I think rust is best positioned. The fact that it is really the only contender that can preform the same role as C, but it folds in lots of the language design theory of the past three decades puts it in a league of its own.

Exactly! This is what makes Rust exciting - as opposed to yawnfests like Go that merely provide a compiled, somewhat faster Python.

Go does have one interesting feature: CSP concurrency built in. Even this was predated by Erlang, though.

Re: A Week with Mozilla's Rust

#88

The example of match usage is really poor. From the looks of it there is no "pattern matching" going on at all here. I don't know the syntax, but even something like this would be a better demonstration: let computed_key = match (key.len() > self.block_size, key.len() self.zero_pad(self.hash(key).digest), (false, true) => self.zero_pad(key), (false, false) => key } At least there is some matching here, unlike in the…

You're right that it's not an ideal example. I think I said that in the post. The context of the article was the week I spent with Rust and the project I actually did with it. There was not a better example in my code to show. I could have contrived something, but it wasn't really in spirit of what I was writing about.

Re: A Week with Mozilla's Rust

#89
post #39

Earlier quoted context omitted.

> Also, does the compiler complain about my example above being not exhaustive? Yes, although the error message isn't very good: crypto.rs:55:23: 59:5 error: non-exhaustive patterns: true not covered crypto.rs:55 let computed_key = match (key.len() > self.block_size, key.len() self.zero_pad(self.hash(key).digest), crypto.rs:57 (false, true) => self.zero_pad(key), crypto.rs:58 (false, false) => key crypto.rs:59 }; err…

it should be expressed with conditionals anyway. match key.len() { k if k > self.block_size => .. k if k .. k => ... or even match key.cmp(self.block_size) { Equal => .. Greater => .. Less => ...

Thanks for the tip!

Re: A Week with Mozilla's Rust

#90
post #57
post #5

I enjoyed the article as I haven't been exposed to much Rust yet, but I was disappointed that the intro didn't match the content The second sentence: > I want a language where I can be much more productive than in C: one in which I do not fear the correctness of my memory management, and don’t have to go through major gyrations to write concurrent code. And we see no explicit demonstrations of the memory management a…

I read the intro as "I like Rust, I'm going to twist my requirements to match", but that may be a bad read of the author.

That wasn't my intention. I didn't decide to like Rust before trying it, I tried it to see if I liked it. I wrote up what I've learned so far. Probably some day this post will seem naive to me, but for now it's the best I could manage.
Post reply on HN