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

51–60 of 104 posts

Re: A Week with Mozilla's Rust

#51

Post by Locke1689 »

catnaroek wrote: post #31
MrMan wrote: post #27

Earlier quoted context omitted.

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…

You haven't mentioned defer/panic/recover, which seems like the strangest aspect of the language to me. It's similar to exceptions, but the mechanism of action is much more complicated semantically.

Re: A Week with Mozilla's Rust

#52

Post by catnaroek »

Locke1689 wrote: post #49
catnaroek wrote: post #24

Earlier quoted context omitted.

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…

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

No tactics.

Re: A Week with Mozilla's Rust

#53

Post by dbaupp »

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.

You can use lifetimes to enforce that a certain thing is static data, and combined with an enum, you get the best of both worlds: compile-time constants require no allocations, but still flexible enough to allow run-time construction:

  enum StringRef {
      Static(&'static str),
      Owned(~str)
  }
and then `error` would take `StringRef` and be called like:

  self.error(Static("trailing characters"))
  // or
  self.error(Owned(fmt!("%u trailing characters", count)))
(There was even a pull request that added this and the corresponding one for vectors to the stdlib, but it didn't landed (yet): https://github.com/mozilla/rust/pull/7599)

Re: A Week with Mozilla's Rust

#54

Post by dbaupp »

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"?

Perfectly possible: https://news.ycombinator.com/item?id=6254278

Re: A Week with Mozilla's Rust

#55

Post by rybosome »

scribu wrote: post #41
lambda wrote: post #16

That seems like a really bad example of pattern matching, as no pattern matching is going on; it's just using the guard statements, and so could be replaced with an if statement: let computed_key = if key.len() > self.block_size { self.zero_pad(self.hash(key).digest) } else if key.len()

So the last statement in a block for a matched if condition gets assigned to the variable? That's pretty cool.

Any language that emphasizes expressions over statements will have this feature. Off the top of my head, that should include Haskell, Scala, CoffeeScript, Ruby, Elixir, Clojure (hell, anything Lisp really)...

The idea is that while you may be able to traverse code-paths with side effects in some of these languages, they encourage treating a line of code (term used loosely, as an expression can span multiple lines) as a computable value. It may take a bit of getting used to at first, but from my own experience, it now feels weird and awkward when a language doesn't.

Reminds me of looking at a nasty language like MUMPS or something, where persistence is built into the core language; statement-oriented languages tend not to be composable.

Re: A Week with Mozilla's Rust

#56

Post by rdtsc »

Locke1689 wrote: post #49
catnaroek wrote: post #24

Earlier quoted context omitted.

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…

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.

Re: A Week with Mozilla's Rust

#57

Post by BruceIV »

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

Re: A Week with Mozilla's Rust

#58

Post by copx »

pcwalton wrote: post #47
regis wrote: post #40

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?

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.

Re: A Week with Mozilla's Rust

#59

Post by BruceIV »

Locke1689 wrote: post #51
catnaroek wrote: post #31

Earlier quoted context omitted.

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…

You haven't mentioned defer/panic/recover, which seems like the strangest aspect of the language to me. It's similar to exceptions, but the mechanism of action is much more complicated semantically.

As I understand it (and I'm not a Go expert), but panic/recover is not idiomatic Go, and they much prefer the style of using a second return parameter for errors. defer is just a useful syntactic construct that becomes complicated when you add in exceptions (but no more so than calling the destructors in C++ stack unwinding).

Re: A Week with Mozilla's Rust

#60

Post by general_failure »

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 something different in their language, is it?

Post reply on HN