14 ms·

A Fresh Look at Rust

379 points by boynamedsue 12y ago

kibwen 12y ago
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 Teepee (http://chrismorgan.info/blog/introducing-teepee.html http://chrismorgan.info/blog/introducing-teepee.html) and Sven Nilsen's Piston (https://github.com/PistonDevelopers https://github.com/PistonDevelopers) for devoting a great deal of energy to figuring out how best to structure Rust APIs that play to the strengths of the language. It's a process of discovery for all of us!
- dbaupp 12y ago
  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.Command.html http://doc.rust-lang.org/nightly/std/io/process/struct.Comma... [2]: http://doc.rust-lang.org/nightly/std/task/struct.TaskBuilder.html http://doc.rust-lang.org/nightly/std/task/struct.TaskBuilder...
  - bjz_ 12y ago
    I'm so glad that Aaron is on the core team, focusing specifically on API design and ergonomics, rather than just the language. He has definitely been applying much needed polish that we need for a slick 1.0 release.
    - sanderjd 12y ago
      Just wanted to also add that in an area of design with lots of strongly held subjective opinion and rampant bikeshedding, Aaron has shown himself to be incredibly thoughtful, well-measured, and diplomatic. Really a great addition to the team!
  - the_mitsuhiko 12y ago
    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.
- muyuu 12y ago
  Speaking of which, Rust is probably an appropriate language to write a safe and fast WSGI dispatcher to go with Flask, or maybe a full server with an embedded Flask-like framework.
ekidd 12y ago
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-copy algorithms, and trying to get my code to compile (but see 3, below). 2. It's possible to write very fast code without compromising memory safety. It's great to see key parsing operations happening in ~100 nanoseconds, with no allocations. 3. 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. 4. The tooling is very good: library management, unit testing, benchmarking, documentation, error messages etc., all work very nicely. Overall, it lacks the instant gratification of a really good scripting language. But I keep finding myself back in Emacs, writing more Rust code for the fun of it. And I really enjoy the combination of low-level code, memory safety, and a useful selection of functional programming features. I'm glad to see a new language in this niche.
- kibwen 12y ago
  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. :)
  - saosebastiao 12y ago
    Two things that come to my mind: 1) General concurrency/parallelism ease of use. It would be nice to have Async/Await a la C#, as well as some easier to use channels and synchronization primitives/functions along the lines of Go or Core.Async. And 2) use of <> for type annotations instead of [], which is much easier to parse when nested.
    - kibwen 12y ago
      Servo is definitely demanding a wide variety of approaches to both concurrency and parallelism, so I expect the facilities for such in Rust to mature very quickly (but faster with more help and feedback!). It's a very important issue that is seeing work from full-time developers as we speak. As for the second point, we've gone beyond the bikeshed (<> and [] are both exactly as ambiguous to the grammar, so it's just an argument of preference by this point) and addressed the root issue with `where` clauses, which prevent you from needing to nest <> at all for a majority (or perhaps plurality, I haven't measured) of function signatures where you previously needed to.
cageface 12y ago
I have a huge hatred towards both the STL and boost and that has existed even before I worked in the games industry. I really don't understand why STL gets so little love. It's a little lean on features maybe but in my experience it just works, and it's fast. Once you get your head around the iterator concept it's pretty simple to use. And with lambdas in C++ I can write code that's almost as concise as Ruby or Scala. Any strongly-typed, flexible collection & algorithm library is going to be complex and require a learning curve.
- stormbrew 12y ago
  In my experience the people who have strongly negative opinions specifically about the STL have it rooted in one of these two things: - They haven't used it much in a very long time and have very bad memories of tracing through the completely opaque SGI STL implementation and its derivatives. - They include std::string and/or std::iostreams as part of the STL, neither of which are part of the original STL and have all sorts of weird warts and poor interactions with the generic algorithm-focused core parts. Not to say there aren't other reasons people dislike it, but these are big ones.
  - cageface 12y ago
    Probably true. I wasn't much of a fan either when I first used it in 1996. It was extremely verbose, slow to compile, and tended to generate compilation error messages that filled the screen. But the experience of using the STL today with the niceties of C++11 and a good compiler like Clang is vastly better. I can now write code almost as concise as Ruby that runs 100x faster, without usually having to worry about memory management. I avoid using the streams stuff though. That chunk of the library could use a serious overhaul. I'm rooting for Rust because it's designed to address the problem spaces I care about most but C++ has improved by leaps and bounds in the last few years.
    - bjz_ 12y ago
      Yeah, Clang has really improved the ecosystem as a whole, as has this decade's updates to the language and libraries. But unfortunately they are all band-aids over some very deep foundational problems that were decided decades ago (I don't blame Bjarne by the way - he didn't have the benefit of hindsight). I am glad we have a new language that takes the best from C++ and sets in on reasonably solid theoretical foundation inspired by languages like ML and Haskell. It's not watertight yet (unlike the formally verified ML), but it is damn better than the current status quo.
jonesetc 12y ago
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 community? I'm certainly not a networking or concurrency expert, so it's difficult to come up with ideas.
- bjz_ 12y ago
  What kind of areas are you interested/experienced in? What would you like to learn? I'm sure there are tons of gaps out there that you could help fill. Maybe the folks on irc.mozilla.org #rust might be able to give you some ideas.
  - jonesetc 12y ago
    Thanks. I'll definitely try out irc for some ideas. My general projects are small automation tasks for myself as well as small web-based apps for myself and friends. That's part of why coming up with ideas for something like rust are a little tricky. The only promising thought I've had is maybe implementing some sort of template preprocessor that I can find a way to work into an existing rust framework.
- zem 12y ago
  you might also like ocaml as a higher-level language with a lot of the same features.
  - mercurial 12y ago
    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...
adultSwim 12y ago
This is a good write-up. I still think some kind of vanilla ML would suit a lot of people very well.
- bjz_ 12y ago
  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.
  - andrewflnr 12y ago
    That's probably why they said "some vanilla ML" instead of naming an implementation.
  - adultSwim 12y ago
    OCaml would be fine. It's a good language with a very efficient run-time. I'm arguing that you could throw out most of the advanced features and that would be enough for most people. Its best features are the core ones. That's why I don't really care which specific flavor of ML you pick. Any would be a big win over many languages in wide use today.
nixpulvis 12y ago
In addition to being a great lang, I love all the little things. Like he mentions, the doc tools and compiler are very nice.
- bjz_ 12y ago
  > the [...] compiler [is] very nice. No doubt clang has been a good influence in setting the standard for gorgeous, readable error messages with nice colored squigglies and arrows. Borrow check errors probably the hairiest you get, and you get less and less of those as you internalise the rules.
ObviousScience 12y ago
I've been very interested in Rust for a while, but put off by the early development status and the fact that it's undergone a few major redesigns. I don't hold them against the language team in any sense, and actually think more of them for it, since redesigns early are good if you realize something else might be better or one of your original ideas just didn't work out. Rather, I'm just curious when I can expect Rust to settle down and not have frequent breaking changes, major redesigns of language features, etc. I've heard it's the aim of the 1.0 release to have this property (which is a reasonable goal in my mind). Does anyone have a timeline on when it would be reasonable to start eyeing Rust if I want more stability (in terms of language features) than it's had during its development phase?
- steveklabnik 12y ago
  You want to wait for 1.0. The plan is a release candidate around the end of the year.
- deleted 12y ago
  [deleted]
- robertfw 12y ago
  There was a blog post recently discussing what is left before a 1.0 release, and the timeline for it. I'm in the same boat as you and the blog post has been helpful because now I can at least feel comfortable learning some basics, while avoiding the areas that are still in flux. http://blog.rust-lang.org/2014/09/15/Rust-1.0.html http://blog.rust-lang.org/2014/09/15/Rust-1.0.html
haberman 12y ago
> 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 of the most important and novel parts of Rust. I'd love to see more detailed examples of where: 1. it kept you from doing something idiomatic that you knew was safe but you just couldn't convince the borrow checker of it. 2. it kept you from doing something that seemed safe, but then you realized that it was actually telling you something important. Also: > Even if it would turn out that the borrow checker is not sound Wait, is this an actual risk? Is there some lingering doubt that the borrow checker is actually sound?
- mcpherrinm 12y ago
  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)
  - haberman 12y ago
    That's a little scary. But giving it solid theoretical justification sounds like a perfect thesis for some CS or math grad student.
    - dbaupp 12y ago
      https://github.com/nikomatsakis/rust-redex https://github.com/nikomatsakis/rust-redex is a theoretical model of the interesting part of Rust (by one of the core-developers). I don't think it's complete though.
    - bjz_ 12y ago
      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.
coolsunglasses 12y ago
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 https://github.com/bitemyapp/learnhaskell
- kibwen 12y ago
  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".
  - mercurial 12y ago
    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.
    - Dewie 12y ago
      > 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.
      - mercurial 12y ago
        I didn't read this way, but fair enough.
    - kibwen 12y ago
      (Warning: not at all a Haskell expert, so please correct me if I'm wrong.) Each language's deriving facilities aren't actually comparable, as Haskell's are actually generic whereas each Rust's are all hand-coded syntax extensions. Also, I believe that it's possible for Haskell code to fail at link time due to libraries providing incompatible typeclasses (contributing to Cabal hell, perhaps?), whereas Rust traits have different restrictions such that if your library compiles, you know that your users will never experience failure due to the traits implemented by other libraries. So even though the Rust devs have clearly taken some degree of inspiration from Haskell, there are enough subtle interactions with other systems that even the familiar features have a distinctly different feel. I will say, though, that in my observations there have been more than a few people from iterative backgrounds who have said that familiarity with Rust was a useful stepping stone to Haskell. So even though I'd hesitate to compare the languages in absolute terms, in relative terms it's true that Rust is probably the iterative language with the most to offer to aspiring Haskellers.
_pmf_ 12y ago
Easy cross-compilation, motherfucker! Do you have it?
- kibwen 12y ago
  Yes, by passing a target to the compiler via the "--target" flag.
bsaul 12y ago
I found the python version of the code so much more readable... is putting "unwrap" and "ignore" everywhere becoming idiomatic in Rust ?
- Argorak 12y ago
  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.
  - dbaupp 12y ago
    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/ - http://doc.rust-lang.org/nightly/std/result/#the-try!-macro http://doc.rust-lang.org/nightly/std/result/#the-try!-macro
    - Argorak 12y ago
      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.
- yen223 12y ago
  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<xxx>?
deleted 12y ago
[deleted]
InfiniteRand 12y ago
Rust actually makes me think a lot about Ada, if you want to program, you need to program correctly. Probably the reason I will not use Rust is the same reason I only look at Ada in a professional context, I usually start projects with something quick and dirty, then gradually refactor it into something better, rather than piece by piece. Being forced to do it right the first time would likely just push me more into doing less programming.
pekk 12y ago
Disappointing how this author's hyper-criticism of Python is not applied equally to Rust, presumably because Rust is newer and this author has other bones to pick with Python. If Rust has a problem, he will sell that it is charming (e.g. "it makes you think", "you just need to think differently", "needs more love"). The glass will be full any day now! But if any new effort in Python is not absolutely perfect or just not to his personal taste, he will sell that it's because Python is a horrible pile of shit because nobody listens to him. The glass isn't only half empty, it is also too hard, too brittle, too cold and actually also too warm and it turns out that not even its transparency is a good feature. After several years of this routine, it has become very old. For God's sake, if your ex is so bad then just move out of her house already. Don't just keep eating the dinners she prepares and complaining about them and saying you'll move out. Actually move out and stop talking about her all the time. Yet another article about how you can't stand how she clips her nails is not helping anyone.
- mercurial 12y ago
  The criticisms of Python covers about one sentence, and they're all to the point. I don't see how you can turn a well-written post 99% about Rust into "hyper-criticism of Python". > he will sell that it's because Python is a horrible pile of shit because nobody listens to him I'm not sure we're talking about the same Armin here...
- Dewie 12y ago
  > , presumably because Rust is newer and this author has other bones to pick with Python. Presumably because this attitude is what you've seen from the author before? Or presumably because you just assume that he is a "Magpie Developer"? If its the latter, that seems like a really unfair presumption.
wisienkas 12y ago
Started using rust just this week. Used more hours than ever expected on it. Simple put you'll fall in love with the compiler, because it point out so well your mistakes. Another thing to note is that it greatly encourage you to fix your warnings too. which for me coming from java and php world isn't something you'd give much thought.
- kibwen 12y ago
  I agree about the warnings. Normal Rust code is already so strict that a lot of the warnings that you'd get from other languages are already compiler errors, which means that issues that are merely good style (e.g. declaring a variable as mutable when you never actually mutate it) can spit out warnings without overwhelming coders and causing them to lapse into "I've already got 200 pages of warnings so screw this" apathy. It's a fine line though, and something we have to remain mindful of as we add more warnings by default.
reflexer 12y ago
let the hype cycle begin

379 points by boynamedsue 12y ago

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 Teepee (http://chrismorgan.info/blog/introducing-teepee.html http://chrismorgan.info/blog/introducing-teepee.html) and Sven Nilsen's Piston (https://github.com/PistonDevelopers https://github.com/PistonDevelopers) for devoting a great deal of energy to figuring out how best to structure Rust APIs that play to the strengths of the language. It's a process of discovery for all of us!

dbaupp 12y ago
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.Command.html http://doc.rust-lang.org/nightly/std/io/process/struct.Comma... [2]: http://doc.rust-lang.org/nightly/std/task/struct.TaskBuilder.html http://doc.rust-lang.org/nightly/std/task/struct.TaskBuilder...
- bjz_ 12y ago
  I'm so glad that Aaron is on the core team, focusing specifically on API design and ergonomics, rather than just the language. He has definitely been applying much needed polish that we need for a slick 1.0 release.
  - sanderjd 12y ago
    Just wanted to also add that in an area of design with lots of strongly held subjective opinion and rampant bikeshedding, Aaron has shown himself to be incredibly thoughtful, well-measured, and diplomatic. Really a great addition to the team!
- the_mitsuhiko 12y ago
  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.
muyuu 12y ago
Speaking of which, Rust is probably an appropriate language to write a safe and fast WSGI dispatcher to go with Flask, or maybe a full server with an embedded Flask-like framework.

ekidd 12y ago

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-copy algorithms, and trying to get my code to compile (but see 3, below). 2. It's possible to write very fast code without compromising memory safety. It's great to see key parsing operations happening in ~100 nanoseconds, with no allocations. 3. 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. 4. The tooling is very good: library management, unit testing, benchmarking, documentation, error messages etc., all work very nicely. Overall, it lacks the instant gratification of a really good scripting language. But I keep finding myself back in Emacs, writing more Rust code for the fun of it. And I really enjoy the combination of low-level code, memory safety, and a useful selection of functional programming features. I'm glad to see a new language in this niche.

kibwen 12y ago
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. :)
- saosebastiao 12y ago
  Two things that come to my mind: 1) General concurrency/parallelism ease of use. It would be nice to have Async/Await a la C#, as well as some easier to use channels and synchronization primitives/functions along the lines of Go or Core.Async. And 2) use of <> for type annotations instead of [], which is much easier to parse when nested.
  - kibwen 12y ago
    Servo is definitely demanding a wide variety of approaches to both concurrency and parallelism, so I expect the facilities for such in Rust to mature very quickly (but faster with more help and feedback!). It's a very important issue that is seeing work from full-time developers as we speak. As for the second point, we've gone beyond the bikeshed (<> and [] are both exactly as ambiguous to the grammar, so it's just an argument of preference by this point) and addressed the root issue with `where` clauses, which prevent you from needing to nest <> at all for a majority (or perhaps plurality, I haven't measured) of function signatures where you previously needed to.

cageface 12y ago

I have a huge hatred towards both the STL and boost and that has existed even before I worked in the games industry. I really don't understand why STL gets so little love. It's a little lean on features maybe but in my experience it just works, and it's fast. Once you get your head around the iterator concept it's pretty simple to use. And with lambdas in C++ I can write code that's almost as concise as Ruby or Scala. Any strongly-typed, flexible collection & algorithm library is going to be complex and require a learning curve.

stormbrew 12y ago
In my experience the people who have strongly negative opinions specifically about the STL have it rooted in one of these two things: - They haven't used it much in a very long time and have very bad memories of tracing through the completely opaque SGI STL implementation and its derivatives. - They include std::string and/or std::iostreams as part of the STL, neither of which are part of the original STL and have all sorts of weird warts and poor interactions with the generic algorithm-focused core parts. Not to say there aren't other reasons people dislike it, but these are big ones.
- cageface 12y ago
  Probably true. I wasn't much of a fan either when I first used it in 1996. It was extremely verbose, slow to compile, and tended to generate compilation error messages that filled the screen. But the experience of using the STL today with the niceties of C++11 and a good compiler like Clang is vastly better. I can now write code almost as concise as Ruby that runs 100x faster, without usually having to worry about memory management. I avoid using the streams stuff though. That chunk of the library could use a serious overhaul. I'm rooting for Rust because it's designed to address the problem spaces I care about most but C++ has improved by leaps and bounds in the last few years.
  - bjz_ 12y ago
    Yeah, Clang has really improved the ecosystem as a whole, as has this decade's updates to the language and libraries. But unfortunately they are all band-aids over some very deep foundational problems that were decided decades ago (I don't blame Bjarne by the way - he didn't have the benefit of hindsight). I am glad we have a new language that takes the best from C++ and sets in on reasonably solid theoretical foundation inspired by languages like ML and Haskell. It's not watertight yet (unlike the formally verified ML), but it is damn better than the current status quo.

jonesetc 12y ago

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 community? I'm certainly not a networking or concurrency expert, so it's difficult to come up with ideas.

bjz_ 12y ago
What kind of areas are you interested/experienced in? What would you like to learn? I'm sure there are tons of gaps out there that you could help fill. Maybe the folks on irc.mozilla.org #rust might be able to give you some ideas.
- jonesetc 12y ago
  Thanks. I'll definitely try out irc for some ideas. My general projects are small automation tasks for myself as well as small web-based apps for myself and friends. That's part of why coming up with ideas for something like rust are a little tricky. The only promising thought I've had is maybe implementing some sort of template preprocessor that I can find a way to work into an existing rust framework.
zem 12y ago
you might also like ocaml as a higher-level language with a lot of the same features.
- mercurial 12y ago
  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...

adultSwim 12y ago

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

bjz_ 12y ago
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.
- andrewflnr 12y ago
  That's probably why they said "some vanilla ML" instead of naming an implementation.
- adultSwim 12y ago
  OCaml would be fine. It's a good language with a very efficient run-time. I'm arguing that you could throw out most of the advanced features and that would be enough for most people. Its best features are the core ones. That's why I don't really care which specific flavor of ML you pick. Any would be a big win over many languages in wide use today.

nixpulvis 12y ago

In addition to being a great lang, I love all the little things. Like he mentions, the doc tools and compiler are very nice.

bjz_ 12y ago
> the [...] compiler [is] very nice. No doubt clang has been a good influence in setting the standard for gorgeous, readable error messages with nice colored squigglies and arrows. Borrow check errors probably the hairiest you get, and you get less and less of those as you internalise the rules.

ObviousScience 12y ago

I've been very interested in Rust for a while, but put off by the early development status and the fact that it's undergone a few major redesigns. I don't hold them against the language team in any sense, and actually think more of them for it, since redesigns early are good if you realize something else might be better or one of your original ideas just didn't work out. Rather, I'm just curious when I can expect Rust to settle down and not have frequent breaking changes, major redesigns of language features, etc. I've heard it's the aim of the 1.0 release to have this property (which is a reasonable goal in my mind). Does anyone have a timeline on when it would be reasonable to start eyeing Rust if I want more stability (in terms of language features) than it's had during its development phase?

steveklabnik 12y ago
You want to wait for 1.0. The plan is a release candidate around the end of the year.
deleted 12y ago
[deleted]
robertfw 12y ago
There was a blog post recently discussing what is left before a 1.0 release, and the timeline for it. I'm in the same boat as you and the blog post has been helpful because now I can at least feel comfortable learning some basics, while avoiding the areas that are still in flux. http://blog.rust-lang.org/2014/09/15/Rust-1.0.html http://blog.rust-lang.org/2014/09/15/Rust-1.0.html

haberman 12y ago

> 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 of the most important and novel parts of Rust. I'd love to see more detailed examples of where: 1. it kept you from doing something idiomatic that you knew was safe but you just couldn't convince the borrow checker of it. 2. it kept you from doing something that seemed safe, but then you realized that it was actually telling you something important. Also: > Even if it would turn out that the borrow checker is not sound Wait, is this an actual risk? Is there some lingering doubt that the borrow checker is actually sound?

mcpherrinm 12y ago
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)
- haberman 12y ago
  That's a little scary. But giving it solid theoretical justification sounds like a perfect thesis for some CS or math grad student.
  - dbaupp 12y ago
    https://github.com/nikomatsakis/rust-redex https://github.com/nikomatsakis/rust-redex is a theoretical model of the interesting part of Rust (by one of the core-developers). I don't think it's complete though.
  - bjz_ 12y ago
    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.

coolsunglasses 12y ago

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 https://github.com/bitemyapp/learnhaskell

kibwen 12y ago
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".
- mercurial 12y ago
  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.
  - Dewie 12y ago
    > 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.
    - mercurial 12y ago
      I didn't read this way, but fair enough.
  - kibwen 12y ago
    (Warning: not at all a Haskell expert, so please correct me if I'm wrong.) Each language's deriving facilities aren't actually comparable, as Haskell's are actually generic whereas each Rust's are all hand-coded syntax extensions. Also, I believe that it's possible for Haskell code to fail at link time due to libraries providing incompatible typeclasses (contributing to Cabal hell, perhaps?), whereas Rust traits have different restrictions such that if your library compiles, you know that your users will never experience failure due to the traits implemented by other libraries. So even though the Rust devs have clearly taken some degree of inspiration from Haskell, there are enough subtle interactions with other systems that even the familiar features have a distinctly different feel. I will say, though, that in my observations there have been more than a few people from iterative backgrounds who have said that familiarity with Rust was a useful stepping stone to Haskell. So even though I'd hesitate to compare the languages in absolute terms, in relative terms it's true that Rust is probably the iterative language with the most to offer to aspiring Haskellers.

_pmf_ 12y ago

Easy cross-compilation, motherfucker! Do you have it?

kibwen 12y ago
Yes, by passing a target to the compiler via the "--target" flag.

bsaul 12y ago

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

Argorak 12y ago
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.
- dbaupp 12y ago
  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/ - http://doc.rust-lang.org/nightly/std/result/#the-try!-macro http://doc.rust-lang.org/nightly/std/result/#the-try!-macro
  - Argorak 12y ago
    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.
yen223 12y ago
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<xxx>?

deleted 12y ago

[deleted]

InfiniteRand 12y ago

Rust actually makes me think a lot about Ada, if you want to program, you need to program correctly. Probably the reason I will not use Rust is the same reason I only look at Ada in a professional context, I usually start projects with something quick and dirty, then gradually refactor it into something better, rather than piece by piece. Being forced to do it right the first time would likely just push me more into doing less programming.

pekk 12y ago

Disappointing how this author's hyper-criticism of Python is not applied equally to Rust, presumably because Rust is newer and this author has other bones to pick with Python. If Rust has a problem, he will sell that it is charming (e.g. "it makes you think", "you just need to think differently", "needs more love"). The glass will be full any day now! But if any new effort in Python is not absolutely perfect or just not to his personal taste, he will sell that it's because Python is a horrible pile of shit because nobody listens to him. The glass isn't only half empty, it is also too hard, too brittle, too cold and actually also too warm and it turns out that not even its transparency is a good feature. After several years of this routine, it has become very old. For God's sake, if your ex is so bad then just move out of her house already. Don't just keep eating the dinners she prepares and complaining about them and saying you'll move out. Actually move out and stop talking about her all the time. Yet another article about how you can't stand how she clips her nails is not helping anyone.

mercurial 12y ago
The criticisms of Python covers about one sentence, and they're all to the point. I don't see how you can turn a well-written post 99% about Rust into "hyper-criticism of Python". > he will sell that it's because Python is a horrible pile of shit because nobody listens to him I'm not sure we're talking about the same Armin here...
Dewie 12y ago
> , presumably because Rust is newer and this author has other bones to pick with Python. Presumably because this attitude is what you've seen from the author before? Or presumably because you just assume that he is a "Magpie Developer"? If its the latter, that seems like a really unfair presumption.

wisienkas 12y ago

Started using rust just this week. Used more hours than ever expected on it. Simple put you'll fall in love with the compiler, because it point out so well your mistakes. Another thing to note is that it greatly encourage you to fix your warnings too. which for me coming from java and php world isn't something you'd give much thought.

kibwen 12y ago
I agree about the warnings. Normal Rust code is already so strict that a lot of the warnings that you'd get from other languages are already compiler errors, which means that issues that are merely good style (e.g. declaring a variable as mutable when you never actually mutate it) can spit out warnings without overwhelming coders and causing them to lapse into "I've already got 200 pages of warnings so screw this" apathy. It's a fine line though, and something we have to remain mindful of as we add more warnings by default.

reflexer 12y ago

let the hype cycle begin