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

81–90 of 157 posts

Re: A Fresh Look at Rust

#81

Post by the_mitsuhiko »

yen223 wrote: post #74
bsaul wrote: post #69

I found the python version of the code so much more readable... is putting "unwrap" and "ignore" everywhere becoming idiomatic in Rust ?

Python made the choice to sacrifice performance for much better readability, and it shows. You can see the difference between code elegance when working with strings in either languages, for example. The downside is that Python's benchmark numbers are poor. Rust can get to within 1x C's performance; Python would be lucky to get within 100x. But I do share your concern about `unwrap`. Is it idiomatic to do `unwrap`s,…

Unwrap only appears in simplistic examples. The correct "unwrap" is the `try!` macro.

Re: A Fresh Look at Rust

#82

Post by bsaul »

the_mitsuhiko wrote: post #76
bsaul wrote: post #69

I found the python version of the code so much more readable... is putting "unwrap" and "ignore" everywhere becoming idiomatic in Rust ?

No, it's just in this example. In idomatic rust you would write this probably: https://gist.github.com/mitsuhiko/1f37c1092bdf54ce4213 The `try!` macro unwraps the okay part of the expression and early returns the err part. The nice thing about the explicit results is that you will do the error handling. With Python you often do not know if an error might come.

Ok, much better. At the risk of looking more like a java try/catch, is it possible to wrap multiple statements in a single try! clause ?

Or at least have some way of saying " if there's any error in this block of code, simply stop execution and forward it to the calling statement"

Re: A Fresh Look at Rust

#83

Post by dbaupp »

Argorak wrote: post #73
bsaul wrote: post #69

I found the python version of the code so much more readable... is putting "unwrap" and "ignore" everywhere becoming idiomatic in Rust ?

Usually, .unwrap_or_else(|e| { fail!("well, that's unexpected") }) You need to handle all results in Rust (because the second option is the error case), or the linter will complain. Considering that failing the task (like in e.g. Erlang) is the standard way to handle errors, yes, this is somewhat idiomatic.

Failing the task isn't the standard way to handle errors; propagating information via the Result type (especially the try! macro) is more conventional, as it allows the caller to handle the problem, failing is very annoying to recover from.

- http://doc.rust-lang.org/nightly/std/result/

- http://doc.rust-lang.org/nightly/std/result/#the-try!-macro

Re: A Fresh Look at Rust

#85

Post by tomp »

kibwen wrote: post #5
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…

This is great feedback, thanks. And if there's anything that you don't like about Rust, please let us know now while we still have a chance to possibly fix it! Only a few short months left until all of our mistakes are forever entombed in Rust 1.0. :)

I think that mutability should also be recorded in types (i.e. even a &mut would not allow you to modify an immutable type). Then, programmers could control whether variants/enums are "fat" (use the maximum amount of memory of any variant in the same type) or "thin" (use the minimum amount of memory for the given variant) by changing the mutability of fields they are stored in.

But I totally understand that you probably have other, well thought-out reasons not to do that.

Re: A Fresh Look at Rust

#86

Post by Argorak »

dbaupp wrote: post #83
Argorak wrote: post #73

Earlier quoted context omitted.

Usually, .unwrap_or_else(|e| { fail!("well, that's unexpected") }) You need to handle all results in Rust (because the second option is the error case), or the linter will complain. Considering that failing the task (like in e.g. Erlang) is the standard way to handle errors, yes, this is somewhat idiomatic.

Failing the task isn't the standard way to handle errors; propagating information via the Result type (especially the try! macro) is more conventional, as it allows the caller to handle the problem, failing is very annoying to recover from. - http://doc.rust-lang.org/nightly/std/result/ - http://doc.rust-lang.org/nightly/std/result/#the-try!-macro

I didn't make that clear enough: I should have qualified by "if the error is indeed fatal at that point".

In the example script, it really doesn't make sense to go on after that.

Re: A Fresh Look at Rust

#87

Post by burntsushi »

ghshephard wrote: post #62
moron4hire wrote: post #48

Earlier quoted context omitted.

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…

I think people are being a fit unfair downvoting you right now (I bumped you up) - but I also disagree with you. When I'm working with a file that purports to be CSV/TSV, with python, I reach out to the CSV module, specify the dialect that created it - and instantly get all the power of being able to identify refer to all the fields, rows without having to otherwise worry about parsing them. Is it 100% bulletproof -…

> And, speaking just for myself - again, I've never seen a CSV/TSV file that the python didn't handle just fine - not to say they aren't out there - you just have to go out of your way to create them.

Indeed. Python's CSV module supports a "strict" mode that will yell at you more often, but by default, it is disabled. When disabled, the parser will greatly prefer a parse over a correct parse. I took the same route with my CSV parser in Rust (with the intention of adding a strict mode later), because that's by far the most useful implementation. There's nothing more annoying then trying to slurp in a CSV file from somewhere and having your CSV library choke on it.

Re: A Fresh Look at Rust

#88

Post by dbaupp »

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 can take some wrangling to avoid space leaks and you often have to be careful about strictness (especially when a small change in the code causes the compiler to miss one of the big optimisations), while languages like Rust and C++ put more control into the hands of the programmer and thus achieve high performance more naturally.

As an example of this, consider the benchmarks game[1]. The Rust and Haskell are on par[2] for the most part.

Except, the Haskell programs are having to pull out all stops to reach this level, they essentially all have a ton of strictness annotations, and are doing manual pointer manipulations and even manual allocations. Of the fastest Haskell solutions (i.e. the ones linked on [2]) I count two that don't use a `Foreign.*` module (pidigits and binary-trees) and only one that uses no !'s (pidigits).

On the other hand, none of the Rust programs use any `unsafe` at all (that is, they are guaranteed to be memory safe, e.g. no risk of out-of-bounds accesses or dangling pointers), and are generally not particularly optimised (e.g. the Rust program that is 85 times slower than the Haskell just appears to have been written without thinking about performance at all... it does a whole formatted printing call for each and every character in the output! The version in-tree[3] is at least 50 times faster and still uses no unsafe code).

(I say this as someone who likes Haskell: I'm the person with the most votes for answers in the [rust] tag on StackOverflow, but I've got even more votes than that for my answers on the [haskell] tag.)

[1]: http://benchmarksgame.alioth.debian.org/

[2]: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

[3]: https://github.com/rust-lang/rust/blob/master/src/test/bench...

Re: A Fresh Look at Rust

#89

Post by codygman »

CmonDev wrote: post #61
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

Rust is meant to be practical, Haskell is more for academia (horrible ML syntax etc.).

You're more intelligent than that. Here you go, here's one recent large practical haskell project:

https://github.com/facebook/Haxl

Re: A Fresh Look at Rust

#90

Post by FreeFull »

the_mitsuhiko wrote: post #81
yen223 wrote: post #74

Earlier quoted context omitted.

Python made the choice to sacrifice performance for much better readability, and it shows. You can see the difference between code elegance when working with strings in either languages, for example. The downside is that Python's benchmark numbers are poor. Rust can get to within 1x C's performance; Python would be lucky to get within 100x. But I do share your concern about `unwrap`. Is it idiomatic to do `unwrap`s,…

Unwrap only appears in simplistic examples. The correct "unwrap" is the `try!` macro.

Once you reach the main function, you have to deal with the errors, since you can't propagate them any further.
Post reply on HN