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

51–60 of 157 posts

Re: A Fresh Look at Rust

#51

Post by jxf »

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?

A regexp would work, but it's usually the wrong level of abstraction to operate at. One wants to say "for the next 2,000 rows, retrieve columns 2 and 4, and the column labeled 'foo'", not write a regexp.

Re: A Fresh Look at Rust

#52

Post by bjz_ »

haberman wrote: post #36
mcpherrinm wrote: post #33

Earlier quoted context omitted.

Soundness bugs come up once in a while, so yeah there is doubts. I wouldn't claim it to be sound until there is at least a proof of soundness of a theoretical model of it (which you can then show the implementation matches)

That's a little scary. But giving it solid theoretical justification sounds like a perfect thesis for some CS or math grad student.

There is actually a CS student working on it... from the University of Washington I think? Check out rust-redex. I don't know what the status is though - it doesn't seem to have been updated in a while.

Anyway the devs have said that whilst a 1.0 release will mean backwards compatibility for language features, they will fix any soundness bugs that come to light.

Re: A Fresh Look at Rust

#53

Post by Too »

moron4hire wrote: post #48
moron4hire wrote: post #38

Earlier quoted context omitted.

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…

The csv library of python has handled every csv i've ever thrown on it, csv is "standardized" enough for that. Just set two things, the delimiter, the escape quote method and be done with it. The output is a list of dictionaries with the column headers as keys, very elegant. The best part is that using the same input you did to read a file you can use to save/modify the file and be sure it will look the same when your client re-opens it. A regexp would take twice the time to write and wouldn't give you half of those features, and it would probably fail at escaping sooner or later, for the same reason as xml can't be parsed with regexps.

Re: A Fresh Look at Rust

#55

Post by mercurial »

moron4hire wrote: post #48
moron4hire wrote: post #38

Earlier quoted context omitted.

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…

Well, if you look at, eg, Python's CSV parsing library, it's been more than enough to cover my needs so far, and handles different CSV flavours. It is much nicer and less error-prone to use than using regexps.

Re: A Fresh Look at Rust

#56

Post by mercurial »

zem wrote: post #21
jonesetc wrote: post #8

I rarely have to do anything as low-level as rust would demand. More often than not I find myself using Python, but I had the same feelings when I started looking into rust a few weeks ago. It was exciting seeing the full pattern-matching, especially. I have a desire to get some experience in the area, but the problem is what to make. Does anyone have any ideas for some smallish libraries that would benefit the commu…

you might also like ocaml as a higher-level language with a lot of the same features.

Yes. Rust borrows quite a few things from the ML family of languages (and things unique to Haskell like "deriving"). OCaml has the advantage of offering very good performance while not having to deal with the borrow checker, but it doesn't have the momentum behind Rust (the community is quite small, and the number of libraries isn't that large). That said, it is a very nice language to work with, and offers a number of features absent from Rust, such as a great module system, structural typing, first-class laziness...

Re: A Fresh Look at Rust

#57

Post by mercurial »

kibwen wrote: post #50
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".

Well, Rust has some kind of typeclasses, #deriving, stuff like that. If what parent means is "if you like the things Rust borrowed from OCaml and Haskell, check out Haskell", it's not unreasonable, especially if addressed to people coming from mostly-imperative languages (C or Python).

I agree that Rust and Haskell do feel mighty different in practice.

Re: A Fresh Look at Rust

#58

Post by stock_toaster »

mercurial wrote: post #56
zem wrote: post #21

Earlier quoted context omitted.

you might also like ocaml as a higher-level language with a lot of the same features.

Yes. Rust borrows quite a few things from the ML family of languages (and things unique to Haskell like "deriving"). OCaml has the advantage of offering very good performance while not having to deal with the borrow checker, but it doesn't have the momentum behind Rust (the community is quite small, and the number of libraries isn't that large). That said, it is a very nice language to work with, and offers a number…

  > OCaml has the advantage of offering very good performance
  > while not having to deal with the borrow checker
My understanding was that OCaml had no support for parallelism -- so a single core is all you get. Is that not the case?

Re: A Fresh Look at Rust

#59

Post by smcl »

moron4hire wrote: post #48
moron4hire wrote: post #38

Earlier quoted context omitted.

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…

You are getting downvoted to hell but I can see what you're meaning. Generally if someone hands you a CSV file there is no guarantee that something mental isn't happening as there is no "CSV" standard. So you're saying that when your task is "process the client's CSV file" you might not necessarily be able to rely on a library handling it correctly, and that you should prepare to get your hands dirty (perhaps hacking together something with a regex or two).

Re: A Fresh Look at Rust

#60

Post by the_mitsuhiko »

dbaupp wrote: post #3
kibwen wrote: post #2

I adore that someone like Armin is so delighted to use Rust. From what I've seen of Flask and his other Python libraries, the level of consideration that he devotes to API design is absolutely inspiring. At such an early stage in the language's history, I'm optimistic that his thoughtfulness in API design will become the baseline for the entire Rust ecosystem. In this vein, I'd also like to credit Chris Morgan's Teep…

Don't forget Aaron Turon (employed by Mozilla to work on the design of the std library), who, among other things, wrote the "fluent" APIs for process[1] and task[2] spawning, which possibly inspired the redis-rs API Armin describes in this post. [1]: http://doc.rust-lang.org/nightly/std/io/process/struct.Comma... [2]: http://doc.rust-lang.org/nightly/std/task/struct.TaskBuilder...

Yep, the command builder of the process module was the inspiration for the pipeline system. Lots of other inspiration came from libserialize where I got loads of the type conversion (and especially tuple code) from.
Post reply on HN