16 ms·

Why Rust? [pdf]

134 points by nercury 11y ago

shadowmint 11y ago
The std::thread::scoped function used here is undergoing some redesign... /grumble /grumble Yes, I know, it'll all eventually settle down, but darn its annoying at the moment trying to use stable.
- steveklabnik 11y ago
  It's actually gone entirely now, so using nightly doesn't help you there. And 80% of Crates.io runs on stable, it really depends on exactly what you're doing. (The 'crossbeam' and 'scoped_threadpool' crates have different implementations of this idea, though.)
  - slimsag 11y ago
    > 80% of Crates.io runs on stable, it really depends on exactly what you're doing. While this is probably factually true -- I've had quite the opposite experience. :( - I want to write benchmarks for my code, but I need `#[feature(test)]` AKA nightly. - I want to [format my Rust code](https://github.com/nrc/rustfmt https://github.com/nrc/rustfmt), but I need nightly. - I want to use Huon Wilson's SIMD crate, which requires nightly. I'm not saying these things should be stable right now, but I am saying if you try to use Rust right now you _will_ encounter a lot of stuff marked as unstable and/or only usable on nightly due to XYZ. I still think Rust is amazing and everyone should give it a shot though, but it's not as stable/polished experience as I think it will be in say a year from now. The language is stable, but the ecosystem just isn't yet. P.S. You've helped me personally all too much over the Rust IRC channel, so thank you a million times for that! :)
    - steveklabnik 11y ago
      You're welcome :) I also think that year-from-now Rust will be way nicer than at the moment, it's absolutely early days. But there's a lot you can do, even on stable, right now. This is why I said it depends on what you're doing. Some use cases have absolutely no choice but to use unstable things. Others have options, and others only use stable. As to your three points: 1. You can configure things so that you only need nightly when doing benchmarking, and run on stable the rest of the time. 2. Compiling `rustfmt` needs nightly, but using it doesn't, as it's a binary. 3. Yeah, the SIMD stuff just happened, so it's gonna take some time.
      - libria 11y ago
        It would be good if the core Rust team owned `rustfmt` the way the Go team owns their extremely opinionated format tool. It heavily enforces very consistent code formatting throughout all publicly available Go code. Developers like to say they want choice when it comes to formatting, but take it away and you're left with resigned programmers who are very productive at reading code. ^^ Perhaps not the right outlet for this, but maybe you can point me to where this discussion is taking place.
        steveklabnik 11y ago
        Yes, our intent is to officially adopt rustfmt, and we expect that it will be widly used. It's just not ready yet. nrc, who's leading up the work, is a Mozilla employee, and in general, everyone wants it to be ready. Software just takes time :)
    - Manishearth 11y ago
      The first two are developer tools. It's fine to have to use nightly at dev time (better, in fact, due to compile time improvements!), and then ensure your build works on stable too. Also, rustfmt is a binary which can work without nightly once you've compiled it.
      - cm3 11y ago
        Rust's users are all developers so there's no distinction between expert and novice users. I built rustfmt with nightly Rust and it dynamically links all kinds of shared objects from the Rust install. This doesn't happen for a simple hello world so there must be something different in rustfmt's build.
        Manishearth 11y ago
        There is an important distinction when it comes to stability. Stability for libraries is much more important that stability for devtools Stability mainly matters when you release a library and it stops working on a newer compiler, breaking everyone downstream. That's a pain for the downstream users, because they need not necessarily understand your library internals, and the software they're building will be completely broken until you update it. If an optional developer tool breaks, it's only you that's affected, not downstream users. You can wait for it to be fixed, no problem. Rustfmt uses internal Rust APIs to parse and reason about the code. It could use something else (like syntex), but that would be more work.
        cm3 11y ago
        Can't rustfmt avoid dynamic linking?
        Manishearth 11y ago
        Actually, I'm surprised it does link dynamically, since Rust binaries are typically statically linked. But yes, it should be able to avoid that.
    - sitkack 11y ago
      Won't nightly be the new stable in about ~15 weeks? That is pretty damn amazing. Using multirust [1] makes it easy to track (cargo,rust) for stable, beta and nightly on a per directory basis, super handy. [1] https://github.com/brson/multirust https://github.com/brson/multirust
      - steveklabnik 11y ago
        Current nightly will be stable in 7 weeks, actually, there's a release a week from tomorrow. That doesn't mean that everything that's available on nightly will be available in stable in seven weeks, of course. Everything lands as stable and then is made stable at some point in the future, at least one full cycle after it's landed. There's lots of pre-Rust 1.0 stuff that's still nightly-only.
        sitkack 11y ago
        Thanks for the clarification. Makes a ton of sense.
  - shadowmint 11y ago
    Just saying it's painful. :) For example, try using https://github.com/serde-rs/serde https://github.com/serde-rs/serde without nightly. Possible? Totally. A right pain compared to using nightly? That too.
- Manishearth 11y ago
  https://crates.io/crates/scoped_threadpool https://crates.io/crates/scoped_threadpool works, btw.
0xdeadbeefbabe 11y ago
> It’s very difficult to write multithreaded code, which is the only way to exploit the abilities of modern machines. QED? Really? I'm not so sure I trust the author to give rust fair treatment anymore. An operating system that does multithreading is not the same as a modern machine. Edit: Any brave down voters want to explain why? Threads are a way to model concurrency. There are other ways.
- AnimalMuppet 11y ago
  I'm not the downvoter. But you may be getting the downvotes because you're throwing out snark ("Really? I'm not so sure I trust the author to give rust fair treatment anymore") and dogmatic statements ("An operating system that does multithreading is not the same as a modern machine") with no explanation or justification. It sounds like you're expecting us to agree with your statement as self-evident, or be relegated to the ranks of it ignorant if we don't. That is, it sounds like a one-up game ("I'm smarter/better informed than you"), rather than real conversation. If you don't want to come across that way, give us some explanation of what you're thinking and why. Give us some evidence that your statement is true. Something besides just dogmatic assertions that you're right and the author of the article is stupid and/or biased. Moving on... In the context of the OS, multithreading (or something essentially equivalent) is the only way to exploit the abilities of "modern" machines. But "modern" doesn't mean very modern (at least, as I understand it). It means the difference between MSDOS and Windows: "Windows is multitasking, whereas DOS... DOS is serially multitasking." (I don't recall who said that, but it was brilliant.) Without this capability, you're only running one program at a time. Now, I don't care if you implement this as "theads" or something else, but if you don't have it, your OS is pretty much worthless, and has been since about 1990.
  - 0xdeadbeefbabe 11y ago
    Thanks for the advice on dogmatism coupled with the statement about having a worthless OS since 1990. > In the context of the OS, multithreading (or something essentially equivalent) is the only way to exploit the abilities of "modern" machines. I noticed that you qualified multithreading with "or something essentially equivalent". I guess you would agree that qualifying it this way is a good idea. Mr Blandy did not care to do that though: "[...] is the only way to exploit the abilities of modern machines." I don't like that because it sounds like he's trying to popularize one approach to concurrency without even acknowledging that it is just one approach.
eklavya 11y ago
Awesome read, really helpful. Thanks :)
0xe2-0x9a-0x9b 11y ago
There is nothing in Rust that would ease solving hard problems. Graphs are unsupported. No transactional memory. No distributed computing. No migration. No support for trying. No memoization. No proofs.
- tptacek 11y ago
  Also, less space than a Nomad. Lame!
- deleted 11y ago
  [deleted]
- btown 11y ago
  One might argue that "guaranteeing your web browser doesn't have memory leaks" is a "hard problem." Ergo https://github.com/servo/servo https://github.com/servo/servo . I agree, though, that the problems you mention are all ones where I'd love to see a greenfield programming language with as much attention to detail and support as Rust has.
  - steveklabnik 11y ago
    (Rust doesn't guarantee an absence of leaks, actually. Just memory safety.)
    - Manishearth 11y ago
      It's still really hard to leak in Rust though. Affine types and all.
    - openasocket 11y ago
      In what conditions could Rust code leak memory, excluding the use of unsafe code? What are the technical reasons you can't guarantee an absence of leaks?
      - steveklabnik 11y ago
SloopJon 11y ago
While I appreciate the direct link that bypasses the email form, here's the page describing the report and its author: http://www.oreilly.com/programming/free/why-rust.csp http://www.oreilly.com/programming/free/why-rust.csp "One of the original designers of the Subversion version control system, [Jim Blandy is] a committer to the SpiderMonkey JavaScript engine, and has been a maintainer of GNU Emacs, GNU Guile, and GDB."
hrjet 11y ago
From page 19: > But all those other languages include explicit support for null pointers for a good reason: they’re extremely useful. [....] The problem with null pointers is that it’s easy to forget to check for them. There is no inherent reason for that; just that mainstream languages which support `null` haven't been checking `null` usage. Some of the recent ones do. For example, Kotlin has non-nullable types by default, and null types have to be explicitly marked and checked for null-ness. Even for Java, null analysis is built into Eclipse with the help of annotations. Though, ofcourse, it would be far nicer to have it baked into the language.
- dllthomas 11y ago
  A null pointer is a perfectly sensible implementation of an optional type.
  - Veedrac 11y ago
    It's different from a traditional Option type, though, in that Option<Option<T>> is inexpressible, and that the distinction between map and flat_map is reduced.
    - jamii 11y ago
      In case anyone thinks that's an academic point, this is exactly the reason who so many dynamic languages can't tell the difference between 'key is not in hashtable' and 'key is in hashtable with value null'. I constantly get bitten by this and similar confusions when writing javascript or clojure.
    - AnimalMuppet 11y ago
      > It's different from a traditional Option type, though, in that Option<Option<T>> is inexpressible. I don't think so. It's just a pointer to a pointer, rather than a single pointer. That is, int **value; and either value == null or *value == null or **value == some value of interest
      - 11y ago
Animats 11y ago
The book is exactly what it says it is. "Why Rust", an argument for Rust. 50+ pages. It's a fun read, but not too useful. My own comment on Rust is that the borrow checker is brilliant, and we'll see that again in other languages. The type/generic system picks up where C++ left off, and is very complex. But that may get better as the mess settles down and gets better documentation. We now need a "programming in Rust" book which is not by one of the Rust developers, who are too close to the design.
- steveklabnik 11y ago
  This little book is basically promotional material for Jim's bigger book, which, at least from the blurb, sounds exactly like what you're looking for.
  - sanderjd 11y ago
    Thanks for clarifying that, I'll be excited to read his book when it comes out. Also looking forward to grabbing a paper copy of yours – thanks for making that happen!
    - stock_toaster 11y ago
      Was there an announcement of a paper edition of the rust lang book somewhere?
      - steveklabnik 11y ago
        https://users.rust-lang.org/t/the-rust-programming-language-is-going-to-be-published-by-no-starch-press/2777 https://users.rust-lang.org/t/the-rust-programming-language-...
        stock_toaster 11y ago
        That's awesome! Looking forward to it coming out. :D
tmaly 11y ago
Is there a Tour of Rust like there is a Tour of Go? I found the Tour of Go very helpful when I first approached the language.
- Maken 11y ago
  There is the Rust book https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/, which explains the basics of the language and the standard library though code snippets, and Rust by Example http://rustbyexample.com http://rustbyexample.com, which goes less in depth but is more interactive.
oneJob 11y ago
I know this not the optimal place for this comment/question, but I think likely that many who are interested in this post would be able to speak to the post. I'm also a huge fan of the Chapel Programming language. Anyone else think they're both hitting a sweet spot and would potentially have a beautiful love child?

134 points by nercury 11y ago

The std::thread::scoped function used here is undergoing some redesign... /grumble /grumble Yes, I know, it'll all eventually settle down, but darn its annoying at the moment trying to use stable.

steveklabnik 11y ago
It's actually gone entirely now, so using nightly doesn't help you there. And 80% of Crates.io runs on stable, it really depends on exactly what you're doing. (The 'crossbeam' and 'scoped_threadpool' crates have different implementations of this idea, though.)
- slimsag 11y ago
  > 80% of Crates.io runs on stable, it really depends on exactly what you're doing. While this is probably factually true -- I've had quite the opposite experience. :( - I want to write benchmarks for my code, but I need `#[feature(test)]` AKA nightly. - I want to [format my Rust code](https://github.com/nrc/rustfmt https://github.com/nrc/rustfmt), but I need nightly. - I want to use Huon Wilson's SIMD crate, which requires nightly. I'm not saying these things should be stable right now, but I am saying if you try to use Rust right now you _will_ encounter a lot of stuff marked as unstable and/or only usable on nightly due to XYZ. I still think Rust is amazing and everyone should give it a shot though, but it's not as stable/polished experience as I think it will be in say a year from now. The language is stable, but the ecosystem just isn't yet. P.S. You've helped me personally all too much over the Rust IRC channel, so thank you a million times for that! :)
  - steveklabnik 11y ago
    You're welcome :) I also think that year-from-now Rust will be way nicer than at the moment, it's absolutely early days. But there's a lot you can do, even on stable, right now. This is why I said it depends on what you're doing. Some use cases have absolutely no choice but to use unstable things. Others have options, and others only use stable. As to your three points: 1. You can configure things so that you only need nightly when doing benchmarking, and run on stable the rest of the time. 2. Compiling `rustfmt` needs nightly, but using it doesn't, as it's a binary. 3. Yeah, the SIMD stuff just happened, so it's gonna take some time.
    - libria 11y ago
      It would be good if the core Rust team owned `rustfmt` the way the Go team owns their extremely opinionated format tool. It heavily enforces very consistent code formatting throughout all publicly available Go code. Developers like to say they want choice when it comes to formatting, but take it away and you're left with resigned programmers who are very productive at reading code. ^^ Perhaps not the right outlet for this, but maybe you can point me to where this discussion is taking place.
      - steveklabnik 11y ago
        Yes, our intent is to officially adopt rustfmt, and we expect that it will be widly used. It's just not ready yet. nrc, who's leading up the work, is a Mozilla employee, and in general, everyone wants it to be ready. Software just takes time :)
  - Manishearth 11y ago
    The first two are developer tools. It's fine to have to use nightly at dev time (better, in fact, due to compile time improvements!), and then ensure your build works on stable too. Also, rustfmt is a binary which can work without nightly once you've compiled it.
    - cm3 11y ago
      Rust's users are all developers so there's no distinction between expert and novice users. I built rustfmt with nightly Rust and it dynamically links all kinds of shared objects from the Rust install. This doesn't happen for a simple hello world so there must be something different in rustfmt's build.
      - Manishearth 11y ago
        There is an important distinction when it comes to stability. Stability for libraries is much more important that stability for devtools Stability mainly matters when you release a library and it stops working on a newer compiler, breaking everyone downstream. That's a pain for the downstream users, because they need not necessarily understand your library internals, and the software they're building will be completely broken until you update it. If an optional developer tool breaks, it's only you that's affected, not downstream users. You can wait for it to be fixed, no problem. Rustfmt uses internal Rust APIs to parse and reason about the code. It could use something else (like syntex), but that would be more work.
        cm3 11y ago
        Can't rustfmt avoid dynamic linking?
        Manishearth 11y ago
        Actually, I'm surprised it does link dynamically, since Rust binaries are typically statically linked. But yes, it should be able to avoid that.
  - sitkack 11y ago
    Won't nightly be the new stable in about ~15 weeks? That is pretty damn amazing. Using multirust [1] makes it easy to track (cargo,rust) for stable, beta and nightly on a per directory basis, super handy. [1] https://github.com/brson/multirust https://github.com/brson/multirust
    - steveklabnik 11y ago
      Current nightly will be stable in 7 weeks, actually, there's a release a week from tomorrow. That doesn't mean that everything that's available on nightly will be available in stable in seven weeks, of course. Everything lands as stable and then is made stable at some point in the future, at least one full cycle after it's landed. There's lots of pre-Rust 1.0 stuff that's still nightly-only.
      - sitkack 11y ago
        Thanks for the clarification. Makes a ton of sense.
- shadowmint 11y ago
  Just saying it's painful. :) For example, try using https://github.com/serde-rs/serde https://github.com/serde-rs/serde without nightly. Possible? Totally. A right pain compared to using nightly? That too.
Manishearth 11y ago
https://crates.io/crates/scoped_threadpool https://crates.io/crates/scoped_threadpool works, btw.

0xdeadbeefbabe 11y ago

> It’s very difficult to write multithreaded code, which is the only way to exploit the abilities of modern machines. QED? Really? I'm not so sure I trust the author to give rust fair treatment anymore. An operating system that does multithreading is not the same as a modern machine. Edit: Any brave down voters want to explain why? Threads are a way to model concurrency. There are other ways.

AnimalMuppet 11y ago
I'm not the downvoter. But you may be getting the downvotes because you're throwing out snark ("Really? I'm not so sure I trust the author to give rust fair treatment anymore") and dogmatic statements ("An operating system that does multithreading is not the same as a modern machine") with no explanation or justification. It sounds like you're expecting us to agree with your statement as self-evident, or be relegated to the ranks of it ignorant if we don't. That is, it sounds like a one-up game ("I'm smarter/better informed than you"), rather than real conversation. If you don't want to come across that way, give us some explanation of what you're thinking and why. Give us some evidence that your statement is true. Something besides just dogmatic assertions that you're right and the author of the article is stupid and/or biased. Moving on... In the context of the OS, multithreading (or something essentially equivalent) is the only way to exploit the abilities of "modern" machines. But "modern" doesn't mean very modern (at least, as I understand it). It means the difference between MSDOS and Windows: "Windows is multitasking, whereas DOS... DOS is serially multitasking." (I don't recall who said that, but it was brilliant.) Without this capability, you're only running one program at a time. Now, I don't care if you implement this as "theads" or something else, but if you don't have it, your OS is pretty much worthless, and has been since about 1990.
- 0xdeadbeefbabe 11y ago
  Thanks for the advice on dogmatism coupled with the statement about having a worthless OS since 1990. > In the context of the OS, multithreading (or something essentially equivalent) is the only way to exploit the abilities of "modern" machines. I noticed that you qualified multithreading with "or something essentially equivalent". I guess you would agree that qualifying it this way is a good idea. Mr Blandy did not care to do that though: "[...] is the only way to exploit the abilities of modern machines." I don't like that because it sounds like he's trying to popularize one approach to concurrency without even acknowledging that it is just one approach.

eklavya 11y ago

Awesome read, really helpful. Thanks :)

0xe2-0x9a-0x9b 11y ago

There is nothing in Rust that would ease solving hard problems. Graphs are unsupported. No transactional memory. No distributed computing. No migration. No support for trying. No memoization. No proofs.

tptacek 11y ago
Also, less space than a Nomad. Lame!
deleted 11y ago
[deleted]
btown 11y ago
One might argue that "guaranteeing your web browser doesn't have memory leaks" is a "hard problem." Ergo https://github.com/servo/servo https://github.com/servo/servo . I agree, though, that the problems you mention are all ones where I'd love to see a greenfield programming language with as much attention to detail and support as Rust has.
- steveklabnik 11y ago
  (Rust doesn't guarantee an absence of leaks, actually. Just memory safety.)
  - Manishearth 11y ago
    It's still really hard to leak in Rust though. Affine types and all.
  - openasocket 11y ago
    In what conditions could Rust code leak memory, excluding the use of unsafe code? What are the technical reasons you can't guarantee an absence of leaks?
    - steveklabnik 11y ago

SloopJon 11y ago

While I appreciate the direct link that bypasses the email form, here's the page describing the report and its author: http://www.oreilly.com/programming/free/why-rust.csp http://www.oreilly.com/programming/free/why-rust.csp "One of the original designers of the Subversion version control system, [Jim Blandy is] a committer to the SpiderMonkey JavaScript engine, and has been a maintainer of GNU Emacs, GNU Guile, and GDB."

hrjet 11y ago

From page 19: > But all those other languages include explicit support for null pointers for a good reason: they’re extremely useful. [....] The problem with null pointers is that it’s easy to forget to check for them. There is no inherent reason for that; just that mainstream languages which support `null` haven't been checking `null` usage. Some of the recent ones do. For example, Kotlin has non-nullable types by default, and null types have to be explicitly marked and checked for null-ness. Even for Java, null analysis is built into Eclipse with the help of annotations. Though, ofcourse, it would be far nicer to have it baked into the language.

dllthomas 11y ago
A null pointer is a perfectly sensible implementation of an optional type.
- Veedrac 11y ago
  It's different from a traditional Option type, though, in that Option<Option<T>> is inexpressible, and that the distinction between map and flat_map is reduced.
  - jamii 11y ago
    In case anyone thinks that's an academic point, this is exactly the reason who so many dynamic languages can't tell the difference between 'key is not in hashtable' and 'key is in hashtable with value null'. I constantly get bitten by this and similar confusions when writing javascript or clojure.
  - AnimalMuppet 11y ago
    > It's different from a traditional Option type, though, in that Option<Option<T>> is inexpressible. I don't think so. It's just a pointer to a pointer, rather than a single pointer. That is, int **value; and either value == null or *value == null or **value == some value of interest
    - 11y ago

Animats 11y ago

The book is exactly what it says it is. "Why Rust", an argument for Rust. 50+ pages. It's a fun read, but not too useful. My own comment on Rust is that the borrow checker is brilliant, and we'll see that again in other languages. The type/generic system picks up where C++ left off, and is very complex. But that may get better as the mess settles down and gets better documentation. We now need a "programming in Rust" book which is not by one of the Rust developers, who are too close to the design.

steveklabnik 11y ago
This little book is basically promotional material for Jim's bigger book, which, at least from the blurb, sounds exactly like what you're looking for.
- sanderjd 11y ago
  Thanks for clarifying that, I'll be excited to read his book when it comes out. Also looking forward to grabbing a paper copy of yours – thanks for making that happen!
  - stock_toaster 11y ago
    Was there an announcement of a paper edition of the rust lang book somewhere?
    - steveklabnik 11y ago
      https://users.rust-lang.org/t/the-rust-programming-language-is-going-to-be-published-by-no-starch-press/2777 https://users.rust-lang.org/t/the-rust-programming-language-...
      - stock_toaster 11y ago
        That's awesome! Looking forward to it coming out. :D

tmaly 11y ago

Is there a Tour of Rust like there is a Tour of Go? I found the Tour of Go very helpful when I first approached the language.

Maken 11y ago
There is the Rust book https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/, which explains the basics of the language and the standard library though code snippets, and Rust by Example http://rustbyexample.com http://rustbyexample.com, which goes less in depth but is more interactive.

oneJob 11y ago

I know this not the optimal place for this comment/question, but I think likely that many who are interested in this post would be able to speak to the post. I'm also a huge fan of the Chapel Programming language. Anyone else think they're both hitting a sweet spot and would potentially have a beautiful love child?