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

A Fresh Look at Rust

lucumr.pocoo.org

Post reply on HN
Print view View original

41–50 of 157 posts

Re: A Fresh Look at Rust

#41

Post by dbaupp »

haberman wrote: post #39
steveklabnik wrote: post #34

Earlier quoted context omitted.

Currently, borrows are always lexical. It'd be nice to have non-lexical borrows. It's on the todo list.

Interesting. What is an example of a non-lexical borrow that could potentially be proven safe?

Searching[1] a data-structure (like a hashmap) will return a borrowed reference to that data, which "freezes" the hashmap while the borrow exists. And, due to lexical borrowing, it is frozen even if there was nothing (that is, if the return value was `None` which contains no references linked to the original map).

The following is currently illegal because the `insert` is trying to modify the borrowed map.

  match some_map.find(&a_key) {
      Some(x) => println!("reference to value {}", x),
      None => {
          println!("not found, inserting instead");
          some_map.insert(a_key, some_value);
      }
  }
#6393 is the relevant issue.

[1]: http://doc.rust-lang.org/nightly/std/collections/struct.Hash... [6393]: https://github.com/rust-lang/rust/issues/6393

Re: A Fresh Look at Rust

#42

Post by Ygg2 »

moron4hire wrote: post #25
burntsushi wrote: post #12

Earlier quoted context omitted.

> Rust is one of those languages where I need to work to make the compiler happy, but once I manage that, the code generally works on the first try. I can confirm this. I have a CSV parser[1] that is maybe twice as fast as Python's CSV parser (which is written in C)+. There's nothing magical going on: with Rust, I can expose a safe iterator over fields in a record without allocating. [1] - https://github.com/BurntSus…

I don't understand. What more do you need out of CSV parsing that any standard regex library doesn't provide?

It's kinda funny, because burntsushi wrote Rust's standard regex library.

Re: A Fresh Look at Rust

#43

Post by callcongressnow »

rz2k wrote: post #32
ekidd wrote: post #4

I've been using Rust to process a large text corpus, and as Armin suggests, it's a really interesting experience. Here are a few things I've noticed so far: 1. Writing Rust code definitely takes more time than Python or Ruby, but it's not bad in practice. I can't measure the productivity difference yet, partly because I'm still learning Rust. I do spend more time thinking about how to write zero-allocation and zero-c…

Over the past few days I have been trying Julia. While I don't have much of an idea what I'm doing yet, and I'm probably doing a lot of unproductive premature optimization for the sake of exploring, I see a similar type of difference compared to R and Python where I have more experience. What I am curious about is why you chose Rust rather than Julia. As I've understood the chatter so far, Rust is great for low level…

As far as I am aware, Julia isn't that fast for string operations yet. The language has been optimized for numerical calculations but they haven't done much work on making working with strings as fast as they could. I remember reading this on a github issue at some point but I can't find the issue at the moment.

Re: A Fresh Look at Rust

#44

Post by newobj »

moron4hire wrote: post #38
pselbert wrote: post #27

Earlier quoted context omitted.

There are plenty of values in a purpose built CSV parser. Several important features, depending on the CSVs you'll be working with are: 1. Sometimes you want to actually write files, in which case you'll want help escaping quoting. 2. Shortcuts for using header information to provide more convenient access into a particular column, rather than always doing it by index. 3. Conveniently slurp in only parts of a file, o…

All things a proper understanding of regex and a minimal understanding of streaming file IO can cover. The whole "if you think regex is the solution to your problem, now you have two problems" thing has gotten out of hand. Regex is not that hard.

So, what is the regex to parse csv?

Re: A Fresh Look at Rust

#45

Post by Tyr42 »

moron4hire wrote: post #38
pselbert wrote: post #27

Earlier quoted context omitted.

There are plenty of values in a purpose built CSV parser. Several important features, depending on the CSVs you'll be working with are: 1. Sometimes you want to actually write files, in which case you'll want help escaping quoting. 2. Shortcuts for using header information to provide more convenient access into a particular column, rather than always doing it by index. 3. Conveniently slurp in only parts of a file, o…

All things a proper understanding of regex and a minimal understanding of streaming file IO can cover. The whole "if you think regex is the solution to your problem, now you have two problems" thing has gotten out of hand. Regex is not that hard.

It's simpler to handle quotes and backslashes escaping commas with a custom parser. And then there's the domain knowledge baked into the lib. Does your regex solution produce excel compatible csv files when you have leading zeros? That's important to some people.

Re: A Fresh Look at Rust

#46

Post by kibwen »

haberman wrote: post #28

> The truth is that the borrow checker is not perfect. The borrow checker prevents you from doing dangerous things and it does that. However it often feels too restrictive. In my experience though the borrow checker actually is wrong much less often than you think it is and just requires you to think a bit differently. I would love to see this explored in more detail. The borrow checker is, from what I can tell, one…

  > it kept you from doing something that seemed safe, but 
  > then you realized that it was actually telling you 
  > something important.
One of the reasons that I know Rust is on to something is how often I've seen this scenario occur on IRC. It's great to watch someone come in with a complaint about appeasing the borrow checker, only to later realize that what they were attempting to do was actually subtly unsafe.

For the former point about things that the borrow checker doesn't have enough information to allow, see http://www.reddit.com/r/rust/comments/279yw3/borrowing_from_... for an example.

Re: A Fresh Look at Rust

#47

Post by Ygg2 »

dbaupp wrote: post #41
haberman wrote: post #39

Earlier quoted context omitted.

Interesting. What is an example of a non-lexical borrow that could potentially be proven safe?

Searching[1] a data-structure (like a hashmap) will return a borrowed reference to that data, which "freezes" the hashmap while the borrow exists. And, due to lexical borrowing, it is frozen even if there was nothing (that is, if the return value was `None` which contains no references linked to the original map). The following is currently illegal because the `insert` is trying to modify the borrowed map. match some…

How exactly does one decide if scope is lexical or non-lexical? Or more precisely how do you tell compiler?

Re: A Fresh Look at Rust

#48

Post by moron4hire »

moron4hire wrote: post #38
pselbert wrote: post #27

Earlier quoted context omitted.

There are plenty of values in a purpose built CSV parser. Several important features, depending on the CSVs you'll be working with are: 1. Sometimes you want to actually write files, in which case you'll want help escaping quoting. 2. Shortcuts for using header information to provide more convenient access into a particular column, rather than always doing it by index. 3. Conveniently slurp in only parts of a file, o…

All things a proper understanding of regex and a minimal understanding of streaming file IO can cover. The whole "if you think regex is the solution to your problem, now you have two problems" thing has gotten out of hand. Regex is not that hard.

I think people who are downvoting me don't understand how ludicrously retarded most people who output CSV are. CSV is not RFC4180. It's whatever bullshit text file your client has handed you and convinced your project manager is your problem to parse, not their problem to generate even remotely correctly. There is no CSV library capable of handling "CSV". Every time someone asks you for it, you better kick and scream or expect to do a custom job.

Re: A Fresh Look at Rust

#49

Post by andrewflnr »

bjz_ wrote: post #20
adultSwim wrote: post #16

This is a good write-up. I still think some kind of vanilla ML would suit a lot of people very well.

What do you mean by 'vanilla ML'? I wasn't sure there were any really around... Ocaml has tons of stuff added, and SML also has lots of added extensions.

That's probably why they said "some vanilla ML" instead of naming an implementation.

Re: A Fresh Look at Rust

#50

Post by kibwen »

coolsunglasses wrote: post #30

Annnd if you'd like to be able to write code as fast as Rust but get it done faster than Python or Ruby, take a look at Haskell. - ex-Python and Clojure user, teach Haskell now. https://github.com/bitemyapp/learnhaskell

It's true that Rust approaches the "if it compiles, it works" property that Haskell has, but otherwise the two languages have very little philosophical or practical overlap. It doesn't make sense to compare them outside the context of "here are examples of programming languages with relatively strong type systems".
Post reply on HN