
Rust 1.5 - steveklabnik
http://blog.rust-lang.org/2015/12/10/Rust-1.5.html
======
wyldfire
Congrats to the team!

I recently wrote my first Rust [1] project. Great experience, IMO. I faced a
lot of interesting challenges because my use case was a little outside of
typical. But I tried to minimize 'unsafe' and I was still satisfied with the
results so far.

I know I've only just scratched the surface of the language and I'm looking
forward to learning more.

[1]
[https://github.com/androm3da/libfaultinj](https://github.com/androm3da/libfaultinj)

~~~
logophobia
Just a small remark. You might want to note in your readme why you'd want to
use a fault-injection library. I wasn't familiar with the concept, and had to
google why you'd want to do that (for testing unexpected errors and the
application's handling of those errors).

~~~
wyldfire
Good suggestion:
[https://github.com/androm3da/libfaultinj/commit/9e11fadf6f8b...](https://github.com/androm3da/libfaultinj/commit/9e11fadf6f8ba8b218e8c074417fc640b93055a9)

------
Cshelton
Congrats first of all!

I love Rust and am using it more and more. I'm very excited for 'cargo watch'.
These tools built into the package manager will be so helpful with peoples'
first time Rust experience. I think I'm going to say it, Rust has my favorite
package management system of any language I've used.

Side Note: I'm also a fan of the 6 week release assembly line Rust has going
on. I'm glad that it's staying consistent.

~~~
kibwen
I was actually suggesting that the Rust devs delay the release until next week
because all the release orchestrators are fully occupied with the bi-annual
Mozilla workweek, but it seems that they've managed to pull it off without a
hitch. :)

------
mangeletti
I've been excited to try Rust for some time now, but I've been holding off,
only because I'm primarily developing web applications and I've heard from a
few people that Rust is better suited for other tasks (based on the built-ins,
packages, etc.?), despite there being at least a few frameworks out there.

What are your thoughts on this? Have things changed? Is the assumption just
dead wrong, and Rust is in fact tremendous for web application development?

~~~
steveklabnik
I have historically been skeptical of Rust as an application-tier language,
but my experiments with it as of late have made me reconsider a bit. The
largest weakness, imho, is the lack of libraries for various standards and
formats: do you really want to implement OAuth yourself? (EDIT: Apparently we
do have OAuth now. ha!) The maturity of the Rails ecosystem has spoiled me.

Here's a random fact that I've always found interesting:
[https://crates.io/](https://crates.io/) uses Rust on the server. It links to
libgit, it does a lot of stuff. It uses about 30 megs of memory, resident, at
all times. Coming from Rails, that's... shocking.

~~~
eddyb
I have witnessed someone implementing OAuth2 themselves:
[https://crates.io/crates/inth-oauth2](https://crates.io/crates/inth-oauth2) I
hope they solved the problem permanently, since this is the third crate
attempting OAuth2 and the first two are abandoned/incomplete.

~~~
rspeer
I don't even know what a "complete" OAuth2 library would be. One that not only
deals with the quirks of existing services that use OAuth2, but anticipates
all future ones?

------
jeffdavis
I know this seems like a trivial issue, but I've been bothered by the try!()
macro for a while. I keep hoping then will adopt the "?" postfix operator to
mean the same thing, because it seems to increase readability a lot.

I'm open to other ideas too, but that seemed like the simplest way to get the
error handling out of the way.

Ordinarily I try hard not to complain about syntax, but this seems to cause
people to use .unwrap() where it's not safe (like a library).

~~~
steveklabnik
There was major movement on the ? syntax last night, actually.

~~~
Argorak
Huh, does that reflect in RFCS or something somewhere?

I'm quite pleased by the current solution and am not such a big fan of "?".

~~~
jeffdavis
I'm curious what you do. Do you use try!() extensively, and fine it just fine?
Or do you use something else, like .unwrap()?

~~~
Argorak
Yep, I just use try!(), with the appropriate From implementations.

------
clessg
How are compile times now? The one barrier I had to using Rust for anything
large was the awful compile times.

Very happy to see the tooling improvements, though. Great work!

~~~
steveklabnik
Well, "now" is relative. When did you last try? They've been steadily dropping
each release, though this latest one isn't as large as the last few.

~~~
clessg
Apologies, I should have mentioned that. It's been about 9 months.

~~~
e12e
I'm not sure what's considered slow or fast, but I just tried a couple of
larger-ish rust projects. All data on a midrange SSD, i7 ~4.4Ghz. Warm disk-
cache, so pratcically everything in RAM.

    
    
      crates.io backend service:
      # Note the thing pulls down lots of dependencies doing
      # install, so this is after a "cargo build;cargo clean":
    
      git clone git@github.com:rust-lang/crates.io.git crates.io.git
      cd crates.io.git/
      ./script/init-local-index.sh 
      multirust run nightly cargo build --release
      multirust run nightly cargo clean
      # 4 threads, ~100% CPU up to compiling the final cargo.io bit,
      # which takes the longest:
      git diff
      diff --git a/Cargo.toml b/Cargo.toml
      index cf99b60..02e54fb 100644
      --- a/Cargo.toml
      +++ b/Cargo.toml
      @@ -5,6 +5,7 @@ version = "0.1.0"
         
      [profile.release]
      opt-level = 2
      +codegen-units = 4
         
      [lib]
      name = "cargo_registry"
    
      $ time multirust run nightly cargo build --release
      real    1m29.082s
      user    4m47.276s
      sys     0m6.196s
    
      # Single threades (default Cargo.toml):
      real    1m41.210s
      user    4m0.376s
      sys     0m5.120s
    

Servo:

    
    
      git clone https://github.com/servo/servo servo.git
      cd servo.git/
      ./mach build --release
    

(Servo also pulls down lots of dependencies, including a full rust
toolchain...)

    
    
      ./mach clean
      time ./mach build --release
      Build completed in 791.07s
      real    13m11.874s
      user    40m21.468s
      sys     0m51.304s
      

At approximately 100% cpu for the first part, either the servo build script
makes sure things are parallelized, or the Cargo.toml-settings are set for
parallell builds (haven't checked).

And finally, a smaller project:

    
    
      git clone https://github.com/Aaronepower/tokei.git
      cd tokei/
      cargo build --release
      cargo clean
      
      $ time cargo build --release
      real    0m30.354s
      user    0m32.708s
      sys     0m0.444s
      

According to tokei (which is a blazingly fast cloc tool), there's ~100k cloc
of rust in servo, ~7500 cloc of Rust in crates.io (but that doesn't include
all the dependencies...).

After doing a clean install of rust stable with multirust, the combined cloc
of stuff under ~/.multirust...cargo/src and tokei is ~11.5k cloc of rust,
along with ~ 1400 cloc of c++.

~~~
caspar
You should note that "cargo clean" causes dependencies to be rebuilt next
build as well; a regular "cargo build" would only re-compile your module and
re-link with already-built dependencies, and so should be a fair bit faster.

~~~
e12e
Good point. I did that on purpose in order to do a full rebuild -- but I
suppose for the purposes of "is rustc fast", it's actually more interesting to
just do a build without clean (although one would have to manually remove the
built binary and/or change the code in order to force a rebuild?).

------
seren
I have a small question : I have installed 1.4 through rustup.sh.

What is the clean way to upgrade to 1.5 ? I don't think there is some kind of
'rustup.sh upgrade' Delete 1.4 & reinstall ? Or downloading rustup 1.5 will
apply a clean install on the existing one ?

~~~
steveklabnik
Run rustup.sh again, and it will Just Work. (If not, that's a bug.) If you
want to have multiple versions installed at the same time,
[https://github.com/brson/multirust](https://github.com/brson/multirust) is
super cool.

Generally speaking, installation is something we're working on: working with
Linux package maintainers, rolling rustup and multirust together and making
them work well cross-platform, etc.

~~~
ones_and_zeros
Any plans to offer official Rust Docker images?

Or is this it?
[https://hub.docker.com/r/jimmycuadra/rust/](https://hub.docker.com/r/jimmycuadra/rust/)

~~~
lambda
What benefit would Docker images have over the existing upstream distribution
or distro packaging? The Rust compiler doesn't have any particularly
complicated dependencies, either installing the binaries directly from rust-
lang.org or installing packages from your distro (if your distro has packages
yet) should work fine.

Container images are great for daemons with possibly complicated dependency
sets that might have conflicting version requirements with other packages and
can benefit from isolation from other packages that containerization gives,
but seem like a pretty heavyweight solution for just installing a compiler.

~~~
Drdrdrq
One benefit: one could install latest version of Rust on any distribution.
Debian stable for instance usually lags behind (with good reason, but
still...). I imagine it is mostly useful for checking out Rust though, not for
normal use.

~~~
lambda
The installer from [https://www.rust-lang.org](https://www.rust-lang.org)
works fine on Debian stable. Right now, you can just use the upstream
rustup.sh script for platforms that don't yet have it packaged (like Debian
stable), or install from your distro for those that do (or use rustup.sh on
those as well if you like).

What I'm not seeing is the value of a Docker image. Rust doesn't have much in
the way of runtime dependencies, which is where the value of a container
generally comes in. I don't know of a platform where Docker image would work
but rustup.sh would not.

~~~
Drdrdrq
So you think running some script on my machine is preferable to running a
container? If I don't like having Rust around, with containers I can just
remove it. With script - yeah, maybe, with some digging for correct parameters
and assuming it cleans up after itself properly (which is far from trivial).

Packages are of course preferable if available and up-to-date.

~~~
steveklabnik
rustup.sh has an --uninstall flag that should remove everything cleanly.

~~~
Drdrdrq
Should. It wouldn't be the first script to have a bug.

------
BuckRogers
I've been writing small libraries in Rust and calling them from Python.
Fantastic pair! Congrats to the Rust team.

------
hatsunearu
cargo install is by far the most interesting one in terms of usability. I was
wondering how to write deployment instructions for my binary program written
in Rust; it's kinda clunky to say "here, open target/release/my_program or
copy it to /usr/share/bin"

------
devy
Homebrew's Rust receipt is still at 1.4 :(

[https://github.com/Homebrew/homebrew/blob/master/Library/For...](https://github.com/Homebrew/homebrew/blob/master/Library/Formula/rust.rb)

~~~
filsmick
This doesn't look like 1.4 but _1.0.0-beta.4_, so much older.

~~~
devy
I've just updated the link.

It is 1.4 as I've brewed rust few minutes ago.

And you get the point, don't need to picky on the specifics.

------
zaczac
Is this coincident with Go 1.5 release?

~~~
steveklabnik
No. We release every six weeks, period. Any resemblance to other releases,
living or dead, is purely coincidental.

~~~
sanxiyn
FYI, Go releases roughly every six months.

From [http://blog.golang.org/go12](http://blog.golang.org/go12), "This new
release comes nearly seven months after the release of Go 1.1 in May. We
anticipate a comparable interval between future major releases." Go 1.3 and
1.4 took six months, 1.5 eight months.

