13 ms·

A taste of Rust

192 points by edwintorok 14y ago

rustc 14y ago
I'm a big fan of rust (hence my username), and would like to know if there have been any non-trivial benchmarks of Rust's compilation time, and the performance of compiled executable. Last I checked Rust took about 40 minutes to compile itself on my laptop. Is it still the case? (I haven't touched Rust for a month or so.) Also, is anyone using Rust in non-toy projects? (Except Mozilla's own servo.)
- dbaupp 14y ago
  Are these the sort of benchmarks (of compiled executables) you are looking for: http://pcwalton.github.io/blog/2013/04/18/performance-of-sequential-rust-programs/ http://pcwalton.github.io/blog/2013/04/18/performance-of-seq... ?
  - rustc 14y ago
    Thanks for the link. They're good, but I'd really like to see the comparison of memory safe version and parallel version, compared to languages which compete on those fronts (as the comments on that post have already requested), as that would really be the selling point of Rust IMO.
    - fzzzy 14y ago
      It's still a little early to be benchmarking the scheduler as it is currently undergoing a large rewrite, I believe.
- MaxSize 14y ago
  > Also, is anyone using Rust in non-toy projects? Since it's not production ready yet: no
  - FreezerburnV 14y ago
    You should double-check what kind of projects are being worked on before saying that it isn't being used for non-toy projects :) I can list at least two off the top of my head: Q^3, which can render Quake 3 maps and will eventually be its own game: https://github.com/Jeaye/q3 https://github.com/Jeaye/q3 Servo, an experimental web browser being written by Mozilla: https://github.com/mozilla/servo https://github.com/mozilla/servo
    - MaxSize 14y ago
      For me, a non-toy project is a project that runs in production, where I can build my business on.
      - erickt 14y ago
        I love rust, but we have not yet finalized the syntax and the semantics yet, so it'd be risky to write mission critical things in it. Our plan is to hit 1.0 by the end of the year. That said, rust has been written in rust, and every commit is tested against our test suite on Linux, OS X, BSD, and Windows. So while the language itself may be changing, any code you write in it at a given point in time should work. It'll just take some (small) effort to keep that code in sync with the compiler. So if you are able to handle that risk, we'd love to have you try it out. It'd really help us find the warts in the language/stdlib before we lock in 1.0.
      - pnathan 14y ago
        Rust isn't there yet in my opinion. The syntax and semantics are still undergoing development, and the standard library is still in the process of definition. If you want to rewrite your codebase on a quarterly to cope with the changes, that's up to you, but I wouldn't. I'm waiting for 1.0 to really start writing code in it.
    - prg318 14y ago
      There is also a Famicom/NES emulator written in rust: https://github.com/pcwalton/sprocketnes https://github.com/pcwalton/sprocketnes
- copx 14y ago
  I would say benchmarking the compiler at this point is a little premature. As far as I know they have not even finalized the language yet.
monkeyfacebag 14y ago
The article doesn't specify what exactly, is permitted by an unsafe vs. safe function. The Rust reference indicates the additional operations permitted by unsafe functions are: 1. Dereferencing a raw pointer. 2. Casting a raw pointer to a safe pointer type. 3. Calling an unsafe function. I was expecting something more along the lines of Safe Haskell (http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-...) which is more about trust than memory safety and, as such, explicitly restricts IO. This isn't a value judgment. I just find it an interesting distinction.
- qznc 14y ago
  In D it usually means "no undefined behavior". For example, you can use the @safe annotation on functions. http://dlang.org/function.html#function-safety http://dlang.org/function.html#function-safety http://dlang.org/safed.html http://dlang.org/safed.html
- kibwen 14y ago
  Indeed, there's been some discussion regarding forcing users to specify what sort of unsafety they desire when using unsafe blocks. There's no syntax whatsoever yet, but consider something like the following: unsafe(no-bounds-checks) { ... } or: unsafe(raw-pointers) { ... } Right now the problem is that once you drop into an unsafe block, everything that is unsafe becomes allowed. Obviously this is bad for correctness and bad for readability.
  - lmkg 14y ago
    It seems to me one of the prime difficulties with trying to differentiate types of unsafe behavior, is that often one will imply another. I recall that in C#, there is only one type of Unsafe block and the only unsafe operations it allows is raw pointer manipulation, but since you could theoretically point into the runtime itself, the set of implied consequences of Unsafe blocks is effectively unbounded. If Rust manages to drop its runtime it's not quite so easily susceptible, but even so, returning a pointer to a vtable outside of the unsafe block implies return-oriented programming implies unbounded capabilities. I guess part of the issue is, what is the goal of marking code as unsafe? The use-case that C# was trying to serve was that you could be consuming a third-party assembly without access to source, and you want to know what are the possible consequences of running it. If Rust's main goal is being able to audit your own code for safety (either by hand or by tools), rather than trusting external binaries, then it makes more sense to take a feature-oriented approach rather than a consequence-oriented one. Rust's pointer taxonomy might also help with providing degrees of consequences. You could, for example, restrict that raw pointers could only be cast to pointers with non-sendable kind, which would let you circumvent type safety while still controlling the scope of possible data races. Restricting lifetimes might be useful too, but that's too far beyond the limits of my experience.
zepolud 14y ago
It might be childish but I just can't force myself to swallow the ugly curly braces and semicolons. Some compromises had to be made, e.g. the lack of tailcalls is a regrettable but nonetheless well justified decision. But why didn't they include a standard indentation style in the language specification itself and get rid of the cruft? They have one for Servo anyway, which is the raison d'etre of the whole language, so it's bewildering to me why it isn't included as a part of the specification. It just pains me to see a promising new language being burdened with an ugly looking syntax when the language itself is quite elegant.
- alcuadrado 14y ago
  Python indentantion-as-block definition has many drawbacks, not to mention the lack of semicolons that forces \ you \ to \ write \ so \ many \ backslashes. They are not the ultimate solution for block definition and line breaking. You must be very used to them, and that's why you find the lack of it irritating, but that's another story. Disclaimer: I code python every day of my life nowadays, I'm not a python hater.
  - jerf 14y ago
    I've written a lot of Python too. When I need to span lines, usually there's an easy way to use parens to do blahblah = long().invocation_of.something(with, lots, of, parameters) which is generally more idiomatic. (Of course one wishes to avoid long lines at all but that's not always possible.)
    - alcuadrado 14y ago
      I found that parnes rule used as an awful hack a lot of times. I use it only when the parens are naturally placed, but there are people that just add two parens to avoid one backslash... completely insane!
      - kzrdude 14y ago
        How is the backslash better? The parantheses can stay if you join two lines or split them.
MaxSize 14y ago
I know there are various pointer type prefixes in Rust (@foo, ~foo, &foo, *foo), 'foo for lifetimes and $foo for macro arguments, but WTH is +foo? https://github.com/mozilla/rust/blob/master/src/librustc/middle/borrowck/loan.rs#L260 https://github.com/mozilla/rust/blob/master/src/librustc/mid... I haven't seen this in the documentation.
- erickt 14y ago
  +foo is an old deprecated feature called a mode that is finally just about to be removed. Because the compiler is written in rust, it can take some time for deprecated things to be fully removed from the language. Modes were supposed to give hints to the compiler whether or not to implicitly copy or move a value into a function, but it was buggy and confusing. So we replaced it with always moving for unique types, and always copying for reference counted types.
- kibwen 14y ago
  A very old, very very deprecated feature. I believe pcwalton's working on removing the last vestiges of it from the compiler as we speak. The feature was called "argument modes", but it's been deprecated for so long that almost nobody remembers precisely how they were used (very few understood it in the first place). They were quite pervasive in the early 0.0 days, and it's taken this long to remove them completely. In addition to the +foo forms, there were also others: -foo, &&foo, ++foo, perhaps more. Be glad that they're gone. :)
- dbaupp 14y ago
  They're called "modes" and were a way of controlling whether parameters were copied or passed by reference etc (I think). It's been deprecated for a while and there's an (ongoing) effort to remove them from the code base, e.g. the example you give has been removed already: https://github.com/mozilla/rust/blob/incoming/src/librustc/middle/borrowck/loan.rs#L260 https://github.com/mozilla/rust/blob/incoming/src/librustc/m... (along with most of the modes from the whole source tree, a big patch landed just a few days ago). (Also, the master branch is not the one to be looking at for the latest changes at the moment: patches are merged into 'incoming', and master hasn't been updated for more than a month.)
Locke1689 14y ago
In contrast to this, array (or, as Rust calls them, "vector") references do not require the compiler to know that the index is in range before that index is dereferenced. It would presumably be possible to use the type system to ensure that indexes are in range in many cases, and to require explicit tests for cases where the type system cannot be sure — similar to the approach taken for pointers. Thus, while it is impossible to get a runtime error for a NULL pointer dereference, it is quite possible to get a runtime error for an array bounds error. It is not clear whether this is a deliberate omission, or whether it is something that might be changed later. I presume that's because the Rust designers didn't want to include a dependent type system. Comments from pcwalton?
- pcwalton 14y ago
  Right.
ww520 14y ago
I actually like Rust's compartmentalized approach to memory allocation. Having task/thread specific heap is very concurrent friendly, great for running programs in multi-processor system.

192 points by edwintorok 14y ago

rustc 14y ago

I'm a big fan of rust (hence my username), and would like to know if there have been any non-trivial benchmarks of Rust's compilation time, and the performance of compiled executable. Last I checked Rust took about 40 minutes to compile itself on my laptop. Is it still the case? (I haven't touched Rust for a month or so.) Also, is anyone using Rust in non-toy projects? (Except Mozilla's own servo.)

dbaupp 14y ago
Are these the sort of benchmarks (of compiled executables) you are looking for: http://pcwalton.github.io/blog/2013/04/18/performance-of-sequential-rust-programs/ http://pcwalton.github.io/blog/2013/04/18/performance-of-seq... ?
- rustc 14y ago
  Thanks for the link. They're good, but I'd really like to see the comparison of memory safe version and parallel version, compared to languages which compete on those fronts (as the comments on that post have already requested), as that would really be the selling point of Rust IMO.
  - fzzzy 14y ago
    It's still a little early to be benchmarking the scheduler as it is currently undergoing a large rewrite, I believe.
MaxSize 14y ago
> Also, is anyone using Rust in non-toy projects? Since it's not production ready yet: no
- FreezerburnV 14y ago
  You should double-check what kind of projects are being worked on before saying that it isn't being used for non-toy projects :) I can list at least two off the top of my head: Q^3, which can render Quake 3 maps and will eventually be its own game: https://github.com/Jeaye/q3 https://github.com/Jeaye/q3 Servo, an experimental web browser being written by Mozilla: https://github.com/mozilla/servo https://github.com/mozilla/servo
  - MaxSize 14y ago
    For me, a non-toy project is a project that runs in production, where I can build my business on.
    - erickt 14y ago
      I love rust, but we have not yet finalized the syntax and the semantics yet, so it'd be risky to write mission critical things in it. Our plan is to hit 1.0 by the end of the year. That said, rust has been written in rust, and every commit is tested against our test suite on Linux, OS X, BSD, and Windows. So while the language itself may be changing, any code you write in it at a given point in time should work. It'll just take some (small) effort to keep that code in sync with the compiler. So if you are able to handle that risk, we'd love to have you try it out. It'd really help us find the warts in the language/stdlib before we lock in 1.0.
    - pnathan 14y ago
      Rust isn't there yet in my opinion. The syntax and semantics are still undergoing development, and the standard library is still in the process of definition. If you want to rewrite your codebase on a quarterly to cope with the changes, that's up to you, but I wouldn't. I'm waiting for 1.0 to really start writing code in it.
  - prg318 14y ago
    There is also a Famicom/NES emulator written in rust: https://github.com/pcwalton/sprocketnes https://github.com/pcwalton/sprocketnes
copx 14y ago
I would say benchmarking the compiler at this point is a little premature. As far as I know they have not even finalized the language yet.

monkeyfacebag 14y ago

The article doesn't specify what exactly, is permitted by an unsafe vs. safe function. The Rust reference indicates the additional operations permitted by unsafe functions are: 1. Dereferencing a raw pointer. 2. Casting a raw pointer to a safe pointer type. 3. Calling an unsafe function. I was expecting something more along the lines of Safe Haskell (http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-...) which is more about trust than memory safety and, as such, explicitly restricts IO. This isn't a value judgment. I just find it an interesting distinction.

qznc 14y ago
In D it usually means "no undefined behavior". For example, you can use the @safe annotation on functions. http://dlang.org/function.html#function-safety http://dlang.org/function.html#function-safety http://dlang.org/safed.html http://dlang.org/safed.html
kibwen 14y ago
Indeed, there's been some discussion regarding forcing users to specify what sort of unsafety they desire when using unsafe blocks. There's no syntax whatsoever yet, but consider something like the following: unsafe(no-bounds-checks) { ... } or: unsafe(raw-pointers) { ... } Right now the problem is that once you drop into an unsafe block, everything that is unsafe becomes allowed. Obviously this is bad for correctness and bad for readability.
- lmkg 14y ago
  It seems to me one of the prime difficulties with trying to differentiate types of unsafe behavior, is that often one will imply another. I recall that in C#, there is only one type of Unsafe block and the only unsafe operations it allows is raw pointer manipulation, but since you could theoretically point into the runtime itself, the set of implied consequences of Unsafe blocks is effectively unbounded. If Rust manages to drop its runtime it's not quite so easily susceptible, but even so, returning a pointer to a vtable outside of the unsafe block implies return-oriented programming implies unbounded capabilities. I guess part of the issue is, what is the goal of marking code as unsafe? The use-case that C# was trying to serve was that you could be consuming a third-party assembly without access to source, and you want to know what are the possible consequences of running it. If Rust's main goal is being able to audit your own code for safety (either by hand or by tools), rather than trusting external binaries, then it makes more sense to take a feature-oriented approach rather than a consequence-oriented one. Rust's pointer taxonomy might also help with providing degrees of consequences. You could, for example, restrict that raw pointers could only be cast to pointers with non-sendable kind, which would let you circumvent type safety while still controlling the scope of possible data races. Restricting lifetimes might be useful too, but that's too far beyond the limits of my experience.

zepolud 14y ago

It might be childish but I just can't force myself to swallow the ugly curly braces and semicolons. Some compromises had to be made, e.g. the lack of tailcalls is a regrettable but nonetheless well justified decision. But why didn't they include a standard indentation style in the language specification itself and get rid of the cruft? They have one for Servo anyway, which is the raison d'etre of the whole language, so it's bewildering to me why it isn't included as a part of the specification. It just pains me to see a promising new language being burdened with an ugly looking syntax when the language itself is quite elegant.

alcuadrado 14y ago
Python indentantion-as-block definition has many drawbacks, not to mention the lack of semicolons that forces \ you \ to \ write \ so \ many \ backslashes. They are not the ultimate solution for block definition and line breaking. You must be very used to them, and that's why you find the lack of it irritating, but that's another story. Disclaimer: I code python every day of my life nowadays, I'm not a python hater.
- jerf 14y ago
  I've written a lot of Python too. When I need to span lines, usually there's an easy way to use parens to do blahblah = long().invocation_of.something(with, lots, of, parameters) which is generally more idiomatic. (Of course one wishes to avoid long lines at all but that's not always possible.)
  - alcuadrado 14y ago
    I found that parnes rule used as an awful hack a lot of times. I use it only when the parens are naturally placed, but there are people that just add two parens to avoid one backslash... completely insane!
    - kzrdude 14y ago
      How is the backslash better? The parantheses can stay if you join two lines or split them.

MaxSize 14y ago

I know there are various pointer type prefixes in Rust (@foo, ~foo, &foo, *foo), 'foo for lifetimes and $foo for macro arguments, but WTH is +foo? https://github.com/mozilla/rust/blob/master/src/librustc/middle/borrowck/loan.rs#L260 https://github.com/mozilla/rust/blob/master/src/librustc/mid... I haven't seen this in the documentation.

erickt 14y ago
+foo is an old deprecated feature called a mode that is finally just about to be removed. Because the compiler is written in rust, it can take some time for deprecated things to be fully removed from the language. Modes were supposed to give hints to the compiler whether or not to implicitly copy or move a value into a function, but it was buggy and confusing. So we replaced it with always moving for unique types, and always copying for reference counted types.
kibwen 14y ago
A very old, very very deprecated feature. I believe pcwalton's working on removing the last vestiges of it from the compiler as we speak. The feature was called "argument modes", but it's been deprecated for so long that almost nobody remembers precisely how they were used (very few understood it in the first place). They were quite pervasive in the early 0.0 days, and it's taken this long to remove them completely. In addition to the +foo forms, there were also others: -foo, &&foo, ++foo, perhaps more. Be glad that they're gone. :)
dbaupp 14y ago
They're called "modes" and were a way of controlling whether parameters were copied or passed by reference etc (I think). It's been deprecated for a while and there's an (ongoing) effort to remove them from the code base, e.g. the example you give has been removed already: https://github.com/mozilla/rust/blob/incoming/src/librustc/middle/borrowck/loan.rs#L260 https://github.com/mozilla/rust/blob/incoming/src/librustc/m... (along with most of the modes from the whole source tree, a big patch landed just a few days ago). (Also, the master branch is not the one to be looking at for the latest changes at the moment: patches are merged into 'incoming', and master hasn't been updated for more than a month.)

Locke1689 14y ago

In contrast to this, array (or, as Rust calls them, "vector") references do not require the compiler to know that the index is in range before that index is dereferenced. It would presumably be possible to use the type system to ensure that indexes are in range in many cases, and to require explicit tests for cases where the type system cannot be sure — similar to the approach taken for pointers. Thus, while it is impossible to get a runtime error for a NULL pointer dereference, it is quite possible to get a runtime error for an array bounds error. It is not clear whether this is a deliberate omission, or whether it is something that might be changed later. I presume that's because the Rust designers didn't want to include a dependent type system. Comments from pcwalton?

pcwalton 14y ago
Right.

ww520 14y ago

I actually like Rust's compartmentalized approach to memory allocation. Having task/thread specific heap is very concurrent friendly, great for running programs in multi-processor system.