Live data from Hacker News

A Fresh Look at Rust

lucumr.pocoo.org

71–80 of 157 posts

Re: A Fresh Look at Rust

#71
post #50

Earlier quoted context omitted.

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.

> it's not unreasonable, especially if addressed to people coming from mostly-imperative languages (C or Python).

Perhaps not, but how it is brought up (and worded) feels a bit dismissive of Rust. Which would be fine, if it were not for the fact that the topic of the thread is Rust, and "try Haskell" comment is very drive-by.

Re: A Fresh Look at Rust

#72
post #61

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

Those academia people love themselves some horrible syntax. /s

Re: A Fresh Look at Rust

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

Re: A Fresh Look at Rust

#74
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, or is it better to define functions to accept and return Option?

Re: A Fresh Look at Rust

#75
post #63
post #5

Earlier quoted context omitted.

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've been using Rust for toy projects for a while, and I gotta say Rust is one of the nicest languages out there. Kudos to the Rust team. As a relative newbie to Rust, one of the biggest hurdles I faced was that of poor documentation. A lot of "rust xxx" searches would link to outdated articles or to stale links in the Rust official docs. I understand that Rust is a young language, and documentation is probably the l…

> A lot of "rust xxx" searches would link to outdated articles or to stale links in the Rust official docs.

Or to an old mirror of the official doc, http://web.mit.edu/rust-lang_v0.9 is the bane of my rustperience.

Re: A Fresh Look at Rust

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

Re: A Fresh Look at Rust

#77
post #63

Earlier quoted context omitted.

I've been using Rust for toy projects for a while, and I gotta say Rust is one of the nicest languages out there. Kudos to the Rust team. As a relative newbie to Rust, one of the biggest hurdles I faced was that of poor documentation. A lot of "rust xxx" searches would link to outdated articles or to stale links in the Rust official docs. I understand that Rust is a young language, and documentation is probably the l…

> A lot of "rust xxx" searches would link to outdated articles or to stale links in the Rust official docs. Or to an old mirror of the official doc, http://web.mit.edu/rust-lang_v0.9 is the bane of my rustperience.

It doesn't help that there's a game called Rust out there!

Re: A Fresh Look at Rust

#78
post #64

Earlier quoted context omitted.

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…

> but it doesn't have the momentum behind Rust (the community is quite small, and the number of libraries isn't that large) How come, given the amount of use it gets in the industry and academia versus Rust that still hasn't reached 1.0?

That's a good question. I think F# and Haskell have stolen a fair amount of OCaml's thunder. Meanwhile, Rust caters to everybody who is tired of C/C++ (putting D in the same position as OCaml, I guess?), while having nice enough constructs that people coming from high-level languages get interested in it. By contrast, OCaml doesn't have the "shiny new" feeling of Rust (also suffers from other issues, such as its standard library/libraries, and the tooling, and the "mlis are documentation" attitude that is fairly prevalent in the community). I'd say with more polish and a lot of marketing, it could easily gain more market share (even though some things have gotten much better since opam).

Sometimes, working in OCaml feels like flying a starship equipped with XVIIIth century cannons. The awesomeness of many of its features is in stark contrast to the gaping holes of its ecosystem (no good INI parsing library in 2014? no usable pure OCaml regexp library?).

Re: A Fresh Look at Rust

#79
post #61

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

Arguably that is either wrong or depends on taste.

Haskell has very little syntax in comparison to something like C or Python and what little is has is very obvious.

I'd much prefer ML/Haskell-ish syntax in Rust, but I know I'm in a minority.

Re: A Fresh Look at Rust

#80
post #71

Earlier quoted context omitted.

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.

> it's not unreasonable, especially if addressed to people coming from mostly-imperative languages (C or Python). Perhaps not, but how it is brought up (and worded) feels a bit dismissive of Rust. Which would be fine, if it were not for the fact that the topic of the thread is Rust, and "try Haskell" comment is very drive-by.

I didn't read this way, but fair enough.
Post reply on HN