Rust 1.5 | Hacker News Reader

Rust 1.5

blog.rust-lang.org

342 pointssteveklabnik149 comments

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

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

Good suggestion: https://github.com/androm3da/libfaultinj/commit/9e11fadf6f8b...

This looks like a really cool utility! What other tools out there provide the same service, and how do they compare to this?

I don't think there are any that I know of. There's several tools that leverage LD_PRELOAD hooks though.

ElectricFence is similar but focusing on out-of-bounds memory accesses. Actually, that's not really fault injection, more like sanitizing bad behavior.

There's other fault injection stuff for linux, usually at different layers (I've seen some that use systemtap, e.g.).

I'm looking for something that simulates network errors (in particular: connect timeouts, read timeouts and sudden disconnects). Randomness would be good, too. Know anything for this that can be applied for individual processes?

Yeah, I am pretty sure this is doable but it's not covered by libfaultinj yet.

I opened an issue [1]. I'll get on it.

[1] https://github.com/androm3da/libfaultinj/issues/1

Awesome!

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.

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

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?

If not for Rust, would you write your app in C++ or Python/Ruby/JS?

Python (currently using), or Go.

Add JS to that list as well, because I've done a little bit of work in Node, but that was before Coroutines (back in the days of yore when "callback hell" was a thing), so I wasn't nearly as excited at the time as I probably would be now.

So no, Rust is not a good option :)

Try Elixir (https://elixir-lang.org). Phoenix framework is awesome and working with it is a pleasure.

Thanks. Elixir looks interesting. I'm apprehensive about the "runs on Erlang" part though (wary of compiles-to or runs-on languages, unless the "to" or "on" is C).

Actually Elixir and Erlang are totally interoperable with zero overhead. They both compile to BEAM virtual machine code. That "runs on Erlang" part is a selling point IMO.

You should become skeptical of languages that compile to C. I can't get into the details because I don't know them very well, but take a look a pcwalton's comment history for a fairly technical discussion of why it makes a poor compilation target.

There is this reference site [1], though I have no personal experience so I am not sure if it is up-to-date.

[1] http://arewewebyet.com/

Edit: According to Steve Klabnik in his comment below, it is not up-to-date.

You can certainly try it out for web applications. It has shortcomings, but I assume that by "try Rust" you don't mean "immediately develop something for production"? :)

I have a deamon running that does a specific reverse proxy thing. I wrote it in Rust, and that has been a very pleasant experience. For example, the excellent support for serialization and deserialization makes working with JSON a breeze :)

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

I have witnessed someone implementing OAuth2 themselves: 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.

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?

For production ready, out of the gate, little config, extensive ecosystem, Rust isn't quite there. It will take much more to get many of the things that other languages/frameworks/libraries already provide that are well tested and stable. But the community is progressing surprisingly fast, so I don't think it'll be long before enough of the helper libraries are well tested and stable that building a web server wouldn't be much more difficult than other options. For just a web server, depending on what you're doing, the benefits of using Rust compared to say Node or Go are still, IMO, not a big list YET. One big thing for me is the Rust types system.

I'm working on a new project now where my web server will be Node, however much of my api and micro services/jobs will be in Rust. I expect it to go well, we'll see.

Rust is immature in general. It will probably make a perfectly good language for web, comparable to e.g. OCaml, though the manual memory management is always going to add a little bit of overhead. IMO the web is a lot like anything else, and the best web languages are just the best general-purpose programming languages.

I haven't written a lot of Rust, but what manual memory management are you referring to? As far as I can tell, the whole point of the language is that you don't have to worry about that if you listen to the compiler.

You have to think about it. You don't have to worry about it.

This sounds like Rust propaganda! It's too slick...

it sounds slick, but for the first few hours you'll think that hell is a nicer place than here because the borrow checker won't be there. it takes a while for it to become slick again and only then you really start to appreciate the language. theory vs practive and all that.

It's sort of the opposite, it's that the compiler won't permit you to neglect any aspect of memory management until it deems your work passable. You think about memory management even more than you would in most languages. The result is you get some guarantees about correctness.

You may have to think about it, but you certainly aren't doing the work of e.g. writing malloc and free statements.

It'll get there simply because the language is doing pretty well and lots of people write web servers but it's not there yet. Once someone figures out "the way" to do an internet-facing async http/http2/websocket server I think we'll see a lot more motion in the Rust web dev space.

I've been toying with a web app[1][2] using hyper[3] as for http connections and ws[4] for web socket connections. This was my first project using anything lower level than Javascript. I had a fairly good experience, my problems stemmed more from not knowing the least bit about memory management rather than lack of libraries. In fact the libraries that are already there tend to be very well documented, with lots of examples and explanations.

1: http://theremins.club

2: https://github.com/runarberg/theremins

3: https://crates.io/crates/hyper

4: https://crates.io/crates/ws

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

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

Great to hear! Thank you.

No problem. To be more specific, https://github.com/rust-lang/rfcs/pull/243#issuecomment-1633... and https://github.com/rust-lang/rfcs/pull/243#issuecomment-1633...

TL;DR: we're still adjusting process a bit, but the idea is that this is "good enough" to actually land, behind a feature gate, to start gaining experience. We still reserve the right to tweak it before it goes stable, but it's better to get it into people's hands, rather than continue to debate the last few minor points.

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 "?".

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

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

Yes, on the RFC: https://github.com/rust-lang/rfcs/pull/243#issuecomment-1633...

It seems really wasteful to be working on a specific macro rather than a general-purpose solution (i.e. an equivalent of do notation or scala's for/yield) that will work for things other than error handling.

If you want duck-typed do, there's https://crates.io/crates/mdo

If you want real do, and I do, then you need HKT, which is a massive upgrade to our type system that will take a very long time. If we can do something simpler in the meantime to ease some pain, then it's worth it.

There was just a burst of conversation on this and I think it will be accepted under a feature gate while they work some Type stuff out

Agreed, if you work with I/O, all the try!(try!(try!())) start making your eyes bleed. The ? suggestion is quite brilliant, been waiting for progress on that for a long time

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!

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.

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

Since then Rust 1.2 had a big focus on performance: http://blog.rust-lang.org/2015/08/06/Rust-1.2.html

I measured ~40% improvement from 2015-05-10 to 2015-10-30. That is, it takes 0.6x time to compile. 2015-05-10 was chosen because Rust 1.0 was released 2015-05-15.

https://github.com/sanxiyn/sandbox/blob/master/rust/time-2.p...

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

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.

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

I'm particularly interested in incremental recompilation. From what I can see it hasn't landed yet (?) - but I can't seem to find any ETA on when it will.

There isn't a strong ETA, no. Everything about internals is basically waiting until after the HIR/MIR work lands, as it would end up changing a lot anyway, so that's where the focus is at the moment.

That doesn't mean the _discussion_ about how it works has to stop in the meantime, though...

Well even a guesstimate would be nice :)

I've been following Rust from sidelines before 1.0 and from my perspective there are advantages but I can also see a lot of pain in porting stuff and moving over and I right now the benefits don't outweigh the risk and cost for me - but having a fast build system (which implies incremental recompilation) along with a default package manager (which it already has) would be enough for me to start working with it seriously.

It's kind of sad that building code is such an instrumental part of developing C++ when it's just about dealing with technical issues of the compiler/language/tools and not the problems I'm trying to solve - anything that gets me away from that while leaving me with similar level of memory control and portability is a big win for me.

So when should I be looking back at it ? 6 months ?

If you want a guess, I guess "in 2016".

There's two components to this. I just asked the relevant people, they said "Six months is a safe guess, we hope sooner, we have ambitious plans, we'll see."

However, there's also something mentioned in this announcement: cargo-check. In terms of the "I'm building a project and I don't want my builds to be slow," I think that cargo-check might even be more important. cargo-check relies on an important insight: many times, when you're compiling, you don't actually care about producing a binary, you care that your code passes typechecking and other passes. cargo-check basically runs those things, and doesn't produce the final binary. Makes sense?

Is this something which the editor plugins can make use of? (as a quick lint/feedback about the code). My guess is that the plugins actually use naked rustc call rather than cargo build.

Currently, it basically runs `rust -Zverbose -Zno-trans`, so yes. If it gets more advanced, we'll see.

What would make you choose swift vs rust at this point? The compile speeds have been getting pretty close to objective-c levels, there is 1st and 3rd party package management and its been recently open sourced and is actually being developed in the open.

On top of that they have the financial backing of apple.

Does Swift run on Windows ? Emscripten ? Android ? Portability is also a big question that Rust has a lot better incentives to solve than Apple.

I got the impression that Linux support is more of a "here iOS/OSX develoeprs - we're aware you don't actually run OSX on your servers so you can share code between client and server now". I was not aware Apple wants to push Swift as a cross platform language.

If it was and their commitment looked credible (ie. they start porting tools like integrating debuggers and stuff on other platforms as well) I would definitely consider it.

For the ignorant among us, do you have a link explaining what HIR/MIR is (and how it relates to Rust)?

I should blog about it, because I keep writing comments. :)

So, the basic process of compiling is:

  source -> AST -> LLVM IR -> asm

At each step, you can do transforms too, so like, LLVM will take in LLVM IR, but before compiling, will simplify/transform it into other IR.

There's a few issues with this. The first is that any processing we want to do, like optimizations, safety checks, etc, has to work on the AST. This means that when the AST changes, these features need to change. This is why compiler plugins aren't stable, we're not ready to stabilize the AST yet. Doing so would mean things like "we can never add a new keyword", or at least, makes that process harder.

The final process for Rust will look like

  source -> AST -> HIR -> MIR -> LLVM IR -> asm

HIR is "higher IR" and MIR is "mid IR". In this sense, LLVM IR is a "low IR". There's two important aspects here: the first is that this decouples the AST from things like plugins, which can operate on the HIR, which we will stabilize. The second is that at each step, things get simpler. Here's an example. We have both regular old if statements, and match, which can do more powerful, structural things. Both are fundamentally jump statements, though, and so we can transform the more complex match into the more primitive if. This means that by writing safety checks, optimizations, and other things against MIR, they're both easier to write, as well as more maintainable.

There's one other minor benefit: Someone who wants to write an alternate compiler could theoretically write MIR -> ASM, and eliminate LLVM entirely. While we have less than zero percent chance of doing that ourselves, it might be nice if you want to support some sort of esoteric platform LLVM doesn't, for example.

Does that all make sense?

It does make sense, and thank you very much for taking the time to explain! :)

What does HIR/MIR mean ?

https://news.ycombinator.com/item?id=10713301

How long is "long"? What sort of time would we be talking about for 100KLOC projects?

I don't know about 100K, but for my 5667 line project, a recent nightly build takes 8 seconds to build on my 2012 macbook pro (4 core 2.3G i7). That is with up-to-date external crates that aren't being rebuilt.

Typecheck happens early, with borrow-checking following soon after, so you get feedback on errors fast, and thus only end up waiting when the compiler is happy with your code. Still, it may be an issue for people who like to do TDD or need to do a lot of run-time verification.

For a big project you'd probably need to split it up into multiple crates to "emulate" incremental compilation, at least until it is supported by the build system.

That exact property is why cargo check works.

You would definitely split that project up into multiple crates at the moment. 100KLOC would take an eternity to compile. My guess would be 15 to 45 minutes for a release build, depending on things like how much you were using generics.

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 ?

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

It's also easy to have multiple versions installed using nix.

Any plans to offer official Rust Docker images?

Or is this it? https://hub.docker.com/r/jimmycuadra/rust/

There aren't any plans at the moment, no.

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.

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.

The installer from 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.

I'd attribute it to IMO bad devops habits encouraged by Docker. It's too easy in Docker to depend on someone's unofficial image ("FROM rustxyz" vs. "FROM debian + download deps + install rust"). Having official images would at least reduce the number of people building their infrastructure on unverified/unofficial images.

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.

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

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

A few reasons:

- It is common for languages to have official Docker images (Java, Ruby, Python, Go, Erlang, Haskell, Julia, etc)

- In August the install process didn't work on my Debian system, eventually got guidance for workarounds from IRC

- Our build farm is docker based, application deployment environment is docker based

- Ensures development environments are identical

- Solves the multiple compiler issue

As much as I use Docker, it'd be tough for me to call it heavyweight. In terms of resource consumption Docker is just a neat wrapper over some functionality that is built in to the kernel, there is no "vm" of any sort, which is a common misconception.

Strongly recommend multirust. It can eat a bit of space if you end up with both stable, beta and nightly installed (but that can still be a good idea -- obviously lots of new projects will experiment with some new features). But multirust takes a lot of cues from other similar tools for sandboxing. I just did:

   $ multirust update
   $ multirust show-default
   multirust: default toolchain: stable
   multirust: default location: (...)

   rustc 1.5.0 (3d7cd77e4 2015-12-04)
   cargo 0.6.0-nightly (e1ed995 2015-10-22)

   $ multirust list-toolchains
   beta
   nightly
   stable

   $ du -hs ~/.multirust/
   996M    /home/e12e/.multirust/

Also worth noting is multirust-rs, a reimplementation of multirust in Rust, which notably adds Windows support. I haven't tried anything fancy with it yet but so far it just works.

https://github.com/Diggsey/multirust-rs

The intention is to unify this, multirust, and rustup.sh. It will probably just be branded "rustup."

Thank you so much for posting this. I was expecting something like this to pop but never tried searching.

rustup.sh is really freaking awesome. I was shocked at how insane it is to set up Go when I peeped at my friend installing it.

Never heard of programming but you still want to compile a project?

Step 1: run rustup.sh (curl -sSf https://static.rust-lang.org/rustup.sh | sh)

Step 2: clone the repo of the project or your regional equivalent

Step 3: cargo build --release (or now with the new cargo install feature, cargo install)

Step 4: Enjoy

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

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"

Homebrew's Rust receipt is still at 1.4 :(

https://github.com/Homebrew/homebrew/blob/master/Library/For...

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

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.

Homebrew receipt has been updated to 1.5 just a few hours later!

https://github.com/Homebrew/homebrew/commit/dee292132fb73820...

Is this coincident with Go 1.5 release?

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

FYI, Go releases roughly every six months.

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

Reply on news.ycombinator.com