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

A Week with Mozilla's Rust

relistan.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: A Week with Mozilla's Rust

#61

Post by mcpherrinm »

general_failure wrote: post #60

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…

Rust does have some new syntax, but I think most of it is justified for making programming in it nicer.

The `~[u8]` would be written `std::unique_ptr` in C++. They're used everywhere in Rust, and having to write out unique_ptr would get awfully tiresome.

The `acc` on its own line is a result of "the last statement gets returned" like many functional languages do. If you were writing C++, you'd write `return acc;` instead. This one is more of a convenience, and you could get away without it.

Re: A Week with Mozilla's Rust

#62

Post by lifthrasiir »

general_failure wrote: post #60

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…

It indicates ownership. If you know C++, ~T in Rust is similar to std::unique_ptr in C++ (ensures that there is only one owner of given value) and @T is similar to std::shared_ptr (ensures that there are one or more owners of given value and the value would be deallocated when the last owner vanishes). But you can't check the correctness of these "smart pointers" in the compile time in C++ while keeping the efficiency; Rust has both the correctness and efficiency (1) by making these important types to built-in constructs.

(1) Still being worked on.

Re: A Week with Mozilla's Rust

#63

Post by TheZenPsycho »

general_failure wrote: post #60

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.

Re: A Week with Mozilla's Rust

#64

Post by anon3132 »

general_failure wrote: post #60

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…

Nothing in the syntax is fundamentally new, especially the semicolon turning an expression into a statement.

~[T] is just a vector.

Re: A Week with Mozilla's Rust

#65

Post by anon3132 »

copx wrote: post #58
pcwalton wrote: post #47

Earlier quoted context omitted.

Well, we have a production-quality optimizer (LLVM). So it'll always take some time to compile. Eventually once all of our LLVM patches are upstream and the versions including the patches make it into common repositories you may be able to use your system LLVM to compile the Rust compiler, at which point the compile times will drop dramatically. We continue to work on compile speed of Rust code all the time.

Will you also work on providing a better Windows package? I don't understand why you don't just bundle all the dependencies, given that they all seem to be open source and redistributable. Call me spoiled but I expect a one-click installer in this day and age. I still haven't tried to actually use Rust because of that and I am sure I am not the only one.

Why bother working on a proper distribution of a package that isn't anywhere near ready?

It will come in its due time.

Re: A Week with Mozilla's Rust

#66

Post by anon3132 »

catnaroek wrote: post #24
klibertp wrote: post #15

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…

As noted by masklinn, the compiler will complain about the non-exhaustive match. Stuff like this makes me want a dependently typed language for practical programming, in which I can express the concept of "this case ought to be impossible", and convince the compiler by supplying a proof. Also, this would eliminate the false dichotomy between "fast, unchecked, unsafe array indexing" and "slow, checked, safe array inde…

Dependent typing would be throwing out the entire type system, and also be incredibly ambitious. Dependent type systems are great, but I think the Rust team made the right decision here.

Re: A Week with Mozilla's Rust

#67

Post by anon3132 »

acqq wrote: post #22
acqq wrote: post #8

Earlier quoted context omitted.

Rust not having the garbage collection as far as I understand can be made to produce routines that are part of C application. As far as I understand, by design Go can't be a "nice" citizen in a C application, the Go routine will bring with itself the whole city it lives in to your flat. So Go applications are something like "compiled, fast Ruby or Python." As far as I understand, Rust should theoretically be a way to…

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.

Re: A Week with Mozilla's Rust

#68

Post by doublec »

rdtsc wrote: post #56
Locke1689 wrote: post #49

Earlier quoted context omitted.

I assume you're familiar with ATS? What don't you like about it?

I am not the original poster but I'll respond to this one: I am familiar with ATS and I don't like that I am only familiar with it from the Language Shootout contest website. I haven't heard of it used in production, no blogs, no news on HN. It is a bad excuse and rather sad but my main charge against it is that it is not popular enough.

I agree not much is heard about it. I blog about it a fair amount on [1]. There's also /r/ats [2]. I use it in production. The backend of my bitcoin mining pool [3] is written in ATS and has about 1% of the total bitcoin mining capacity and has been operating for a couple of years. The front end of the pool is written in Ur/Web.

[1] http://bluishcoder.co.nz/tags/ats/ [2] http://www.reddit.com/r/ATS/ [3] http://mmpool.bitparking.com

Re: A Week with Mozilla's Rust

#69

Post by lcampbell »

acqq wrote: post #45
kibwen wrote: post #42

Earlier quoted context omitted.

> What I consider missing for "properly" interfacing with > C is for Rust to be able to slurp C headers as they are, > without the need for additional "translation" files that > are presented in the article. rust-bindgen (modeled after Clay's bindgen tool) has you covered: https://github.com/crabtw/rust-bindgen/ C header files go in, the proper Rust definitions come out. There are long-term plans to adopt this as an…

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.

This is roughly what cgo does, but cgo AFAIK (at least, in 1.0.3 in earlier) does not fully comprehend C preprocessor macros, which are used all over the place in some libraries to define both functions and structs, largely for compatibility reasons. Taking a random example, OpenSSL's EVP_CIPHER_CTX_block_size is a macro that simply returns an internal struct field; to call it from Go, it needs to be explicitly wrapped into a C function. I presume this is because cgo can't infer the signature.

For other things, like some of the constants ncurses defines, it's much less clear what's going on (specifically, I had a hard time with any macro defined with the NCURSES_ACS macro, though that was pre-Go1 -- I believe cgo can now use these macros directly).

There's an additional impedance mismatch when the C headers use macros for conditional compilation (for, e.g., cipher suites that can be optionally compiled out), but it's not a worry if you either are conservative with the functionality you use, or control the packages installed on a system.

I haven't had a chance to play with Rust yet, but since it uses C linkage directly for it's FFI layer, I suspect these problems are less easily addressable.

Re: A Week with Mozilla's Rust

#70

Post by dbaupp »

general_failure wrote: post #60

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…

Note that that loop function now looks like (the for loop has changed since 0.7):

    fn hexdigest(&self) -> ~str {
      let mut acc = ~"";
      for &byte in self.digest.iter() { 
        acc.push_str(fmt!("%02x", byte as uint));
      }
      acc
    }
Post reply on HN