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

31–40 of 104 posts

Re: A Week with Mozilla's Rust

#31

Post by catnaroek »

MrMan wrote: post #27
catnaroek wrote: post #25

Earlier quoted context omitted.

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

agreed. no fan of Go.

I am no fan of Scheme either, but at least I admit it had one big contribution: the idea that a language ought not to be measured by the number of its features, but by the number of things its features can express when combined.

The situation with Go is completely different. Go is just... meh. Its concurrency model is worse than Erlang's, which predates it. Its type system is worse than Standard ML's, which predates it. Its runtime efficiency is noticeably worse than C++'s, especially so when using customized allocators and avoiding exceptions and RTTI. In short, Go is mediocre.

Re: A Week with Mozilla's Rust

#32

Post by pcwalton »

acqq wrote: post #28
pcwalton wrote: post #26

Earlier quoted context omitted.

> 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 and minimalistic := and Rust the clumsy (for my aesthetics at least) "let." It is not possible for us to have ":=" because we don't know whether to parse a pattern or an expression without a prefix token like "let". Rust's pattern language is far more expressive than Go's and one gramm…

Does it mean that to do self.error(~"trailing characters") there has to be the complete allocation of enough memory to store the copy of the whole string, then copying of all characters there, only in order for the target function to be able to do "free"? If the intention of the language is to "properly" work with a lot of strings (and it should be) it would be good not to have glaring inefficiencies? Wouldn't it be…

> If the intention of the language is to "properly" work with a lot of strings (and it should be) it would be good not to have glaring inefficiencies? Wouldn't it be a good optimization to have the free routine check if the pointer is inside of the static area and then not do anything.

You can implement that yourself, by using an enum for example or by using a custom smart pointer. The moment you start adding more magic to "free" beyond "call free" you become less low level of a language.

Re: A Week with Mozilla's Rust

#33

Post by acqq »

bct wrote: post #29
acqq wrote: 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…

I'm new to Rust and I'm not familiar with this code, but here's an attempt at an explanation anyways: The "error" function returns a struct containing the error string. I suspect the intention is to allow dynamically constructed error messages like "syntax error at line 4, char 3" (although it doesn't seem to be doing this anywhere). Since the string might be dynamically allocated, it has to be freed when the struct…

If you wanted an "error" function that would take string literals directly (and only string literals)

And how about some convenient "either or"?

Re: A Week with Mozilla's Rust

#34

Post by [deleted] »

acqq wrote: post #33
bct wrote: post #29

Earlier quoted context omitted.

I'm new to Rust and I'm not familiar with this code, but here's an attempt at an explanation anyways: The "error" function returns a struct containing the error string. I suspect the intention is to allow dynamically constructed error messages like "syntax error at line 4, char 3" (although it doesn't seem to be doing this anywhere). Since the string might be dynamically allocated, it has to be freed when the struct…

If you wanted an "error" function that would take string literals directly (and only string literals) And how about some convenient "either or"?

[deleted]

Re: A Week with Mozilla's Rust

#35

Post by acqq »

pcwalton wrote: post #32
acqq wrote: post #28

Earlier quoted context omitted.

Does it mean that to do self.error(~"trailing characters") there has to be the complete allocation of enough memory to store the copy of the whole string, then copying of all characters there, only in order for the target function to be able to do "free"? If the intention of the language is to "properly" work with a lot of strings (and it should be) it would be good not to have glaring inefficiencies? Wouldn't it be…

> If the intention of the language is to "properly" work with a lot of strings (and it should be) it would be good not to have glaring inefficiencies? Wouldn't it be a good optimization to have the free routine check if the pointer is inside of the static area and then not do anything. You can implement that yourself, by using an enum for example or by using a custom smart pointer. The moment you start adding more ma…

Can I ask in the language if the address points to the item constructed by the compiler in the static area?

The thing I miss most in C is the possibility for the some kind of"introspection" -- reaching out to the info that the compiler or linker has to know anyway. As far as I know D language is very good for such things.

Re: A Week with Mozilla's Rust

#36

Post by pitterpatter »

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…

>but I doubt Rust has something like this.

Oh, but it does! There's the cond! macro:

    let computed_key = cond!(
        (key.len() > self.block_size) { self.zero_pad(self.hash(key).digest) }
        (key.len()

Re: A Week with Mozilla's Rust

#37

Post by pcwalton »

jkbyc wrote: post #19
Goosey wrote: 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 agree, the actual content doesn't match the introduction so well. I've been looking into Rust during the past few days and I must say I got stuck on the memory model - all the different pointers and their interaction with ownership and mutability, closures capturing their environment (variables outside the closure in the scope where the closure is defined), reference binding, and then things like std::Cell which on…

> all the different pointers

@ is going to sink into the library and will be deemphasized in the language to help with this. That leaves only ~ (pointers) and & (references).

> closures capturing their environment (variables outside the closure in the scope where the closure is defined)

Right, this is one of the difficult pieces. This is going away as well in favor of Java-like Runnables to make the variable capture easier to understand (with macro sugar to make them just as convenient as closures). The closures that remain will work just like the closures you know from other languages regarding variable capture, and the Rust-specific stuff regarding variable capture will be gone.

> std::Cell

Yeah, this needs to be better documented. Part of the problem is that we haven't totally nailed down what Cell will be used for yet.

Re: A Week with Mozilla's Rust

#38

Post by pcwalton »

acqq wrote: post #35
pcwalton wrote: post #32

Earlier quoted context omitted.

> If the intention of the language is to "properly" work with a lot of strings (and it should be) it would be good not to have glaring inefficiencies? Wouldn't it be a good optimization to have the free routine check if the pointer is inside of the static area and then not do anything. You can implement that yourself, by using an enum for example or by using a custom smart pointer. The moment you start adding more ma…

Can I ask in the language if the address points to the item constructed by the compiler in the static area? The thing I miss most in C is the possibility for the some kind of"introspection" -- reaching out to the info that the compiler or linker has to know anyway. As far as I know D language is very good for such things.

> Ca I ask in the language if the address points to the item constructed by the compiler in the static area?

It'd require some OS-specific magic. But you could probably do it.

Re: A Week with Mozilla's Rust

#39

Post by kzrdude »

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

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

Re: A Week with Mozilla's Rust

#40

Post by regis »

Rust looks really great and I would love to switch all of my C development over to Rust but last time I tried to compile it, it took a good hour or two. Has this changed at all?
Post reply on HN