
Announcing Rust 1.12 - steveklabnik
https://blog.rust-lang.org/2016/09/29/Rust-1.12.html
======
kibwen
MIR is here! End-users probably aren't going to be too excited about this just
yet, since MIR's focus in 1.12 is in ensuring there are no correctness
regressions (always a risk when you rewrite an enormous portion of your
middle-end) or noticeable runtime perf or compile-time perf regressions. I do
recall pcwalton remarking that MIR improved Servo's compile times by about
20%, though this is probably not what one would expect across the board. In
any case, the upcoming 1.13 release is where the rubber is really going to
start meeting the road: middle-end optimizations that operate on the MIR (i.e.
[https://github.com/rust-lang/rust/pull/36388](https://github.com/rust-
lang/rust/pull/36388) ); outright removing old trans (which remains in 1.12
via a compiler flag) which allows us to actually start taking advantage of
non-zeroing drop (a long-held dream!); an initial spike for incremental
recompilation; plus big miscellaneous performance improvements such as
[https://github.com/rust-lang/rust/pull/36524](https://github.com/rust-
lang/rust/pull/36524) . As ever, no matter how exciting Rust's present is, it
somehow seems that its future is even more so. :P

(Which isn't to overshadow Jonathan Turner's heroic compiler error message
overhaul that has been long in the works, or the dozens and dozens of new
volunteers who answered the call to help us transition:
[https://github.com/rust-lang/rust/issues/35233](https://github.com/rust-
lang/rust/issues/35233) . But I've had the new error messages enabled for
months now, and it's easy to forget that not everyone has been enjoying them
this whole time!)

~~~
pc2g4d
I'm also excited about the possibilities MIR opens up. As I recall, non-
lexical lifetimes depended on MIR. Does anybody know what the current ETA is
for that feature?

~~~
steveklabnik
It's still in the pre-RFC phase, so there's no solid ETA. This was in fact one
of the largest blockers, though, so we'll see how it goes. To make the status
of MIR more clear:

    
    
      * 1.11: "old trans" by default, MIR with a flag
      * 1.12: MIR by default, "old trans" with a flag
      * 1.13: MIR only, "old trans" is gone
    

Given that we've had 6 weeks so far with MIR-by-default, everything is looking
good, but in theory, making it more widely available might turn up issues. If
something catastrophic happens, in theory, old trans could be brought back. So
we'll see how the next few weeks goes.

That doesn't mean _no_ work has been done on non-lexical lifetimes, see
[http://smallcultfollowing.com/babysteps/blog/2016/05/09/non-...](http://smallcultfollowing.com/babysteps/blog/2016/05/09/non-
lexical-lifetimes-adding-the-outlives-relation/) (that's a link to the last of
three posts). But there's still work to write an actual RFC, discuss it, and
then land it.

~~~
adelarsq
The information about lifetimes will be available to IDEs? So may be possible
to identify lifetimes by the color from each variable
[https://medium.com/@evnbr/coding-in-
color-3a6db2743a1e#.lu50...](https://medium.com/@evnbr/coding-in-
color-3a6db2743a1e#.lu5021d0u)

------
computerphage
It's been really cool watching the design and development of the new error
messages from the outside. There was significant inspiration drawn from the
Elm language's fantastic error messages [1] and even a project that provided
something similar (but not built into rustc) [2].

I've always thought that Rust's command line tooling is really top notch. The
language may be complex, but the authors of rustc make it a point of pride to
make it as easy as possible for users anyway. The new errors will make it that
much easier to learn and be productive in Rust.

Also, the community involvement in this release is really spectacular. There
were 83 participants working together on the new error messages [3] and 176
total involved directly with the rust compiler just for 1.12! (ok, well,
including a few bots)

[1] [https://internals.rust-lang.org/t/compiler-errors-for-
humans...](https://internals.rust-lang.org/t/compiler-errors-for-
humans/2310/10) [2]
[https://www.reddit.com/r/rust/comments/3totkg/dybuk_the_elml...](https://www.reddit.com/r/rust/comments/3totkg/dybuk_the_elmlike_rustc_error_pretty_printer/)
[3] [https://github.com/rust-lang/rust/issues/35233](https://github.com/rust-
lang/rust/issues/35233)

~~~
santaclaus
> The language may be complex

Compared to what?

Edit: This was not meant as a slight, I quite like Rust's comapritive
simplicity when held up to other non-GC 'systems' languages.

~~~
duaneb
To answer you seriously—I think a great contrast would be the simplicity of
Go. The GC and type system are both the opposite of providing complexity to
the user; they provide the only way to get anything done, and it's easy to
keep in your head.

For the record, I prefer rust.

~~~
ffggvv
I would like to switch from go to rust. But rust's standard library isn't as
mature as that of go. Do you think there are compatible crates to packages
from go's standard library.

I need

* json/gzip/etc. * string manipulation * good unicode support (normalization, etc.)

not much actually.

And one important question: which one do you think is best for large projects?
Both were built to deal with difficulties rising from large projects but took
two opposite directions...

~~~
pcwalton
> But rust's standard library isn't as mature as that of go.

I'm not really sure that's true. Rust probably has a smaller standard library
overall, but there are things that it has that Go doesn't: B-trees, native OS
string encodings, functional tools, round(), etc.

The bigger point is that the crates.io ecosystem readily has support for
everything you're asking for, and it's much easier to pull in third-party
dependencies in Rust.

~~~
Gankro
I am fairly certain I successfully got binary trees deleted from the standard
library. If you monsters added it back, so help me god...

(BTrees, on the other hand, thrive)

~~~
pcwalton
Sorry about that. Corrected myself.

------
moosingin3space
Thank you, Rust standard library maintainers, for making it very easy for me
to contribute `BinaryHeap::peek_mut` to the stdlib, which landed in stable
today!

~~~
exDM69
Nice contribution!

I was just browsing the apidocs of peek_mut. Can you share a motivating use
case? It wasn't immediately obvious to me.

~~~
kzrdude
I imagine if every item in the heap is a queue itself, you could use peek mut
to get an item off the current max queue. After the modification, the former
max element is sifted down to account for it's (probably) changed key.

~~~
CUViper
The documentation really should mention the resifting, and why this is useful.
It only mentions that the heap may be inconsistent if the `PeekMut` isn't
properly dropped, without explaining why.

It's basically replacing the former (never stabilized) `push_pop` and
`replace`, which Python folks can relate to similar methods in their `heapq`,
for instance. With separate `push` and `pop` calls, the heap must be sifted
twice, but with `peek_mut` you can update the head in-place and sift only
once.

~~~
carols10cents
I agree-- you should send in a PR to the docs!

------
clarkmoody
Optional JSON output for the compiler error messages is a really cool feature.
This could improve web-technology-based Rust development (browsers, Electron
apps), giving nice feedback to the editor, which could implement the error
message highlighting _right there in your code_.

~~~
steveklabnik
I'll just leave this here:
[https://github.com/nrc/rustw](https://github.com/nrc/rustw)

~~~
adelarsq
It reminds me Play Framework!

------
Jtsummers
[https://github.com/rust-lang/cargo/pull/2857](https://github.com/rust-
lang/cargo/pull/2857)

This will be nice. I couldn't possibly sell rust to my employers if we had to
go to an outside source for packages like [EDIT: rust/crate currently does,
with crates.io]. Being able to host our own mirrors (for CM purposes, if
nothing else) is essential.

~~~
vvanders
FWIW hosting your own mirror is possible today. It just requires a bit of work
to match the crates.io format and specify it via .cargo/config
([http://doc.crates.io/config.html](http://doc.crates.io/config.html)). You
can specify the index url as a "file://" and point it anywhere you like.

Definitely like this new approach though.

~~~
Jtsummers
Thanks. My (limited) search for this a couple months back didn't turn anything
up. This will be useful for my personal projects (I often work offline).

------
brainspider
I like the look of this language, and loaded it up to play around with for the
first time yesterday. This was the first thing that struck me when I compiled
the obligatory hello world..

    
    
      09/29/2016  04:51 PM         1,746,638 main.exe
      09/29/2016  04:51 PM                43 main.rs
    

1.7Mb for the exe from 43 bytes of code on windows 10. :/

AllTheLibs? I'm hoping I can improve on that a bit.

~~~
georgemcbay
1.7 megabytes is essential nothing in both modern disk/flash space and network
costs. This isn't to say that efficient, small code isn't important, but it
seems really common for a lot of programmers to freak out when there's some
minimum executable size required for general "runtime" stuff, even when
practically speaking it doesn't really matter in the real world outside of
niche embedded system applications.

If each 43 bytes you compiled expanded to ANOTHER 1.7mb, then, yeah, that's
not good, but that isn't the case here.

~~~
elihu
It might not matter to an individual user or developer, but if Rust is to be
successful in the long run I think it's important for Rust-based desktop
applications to be adopted.

If an application wants to be included in the standard install of, say,
Ubuntu, one of the biggest costs from the Ubuntu maintainer's point of view is
going to be "how much space will this take up on the iso, and what are we
going to have to remove if we include this?" If the binaries are very small,
it's a lot easier to make the case that they should be included.

~~~
steveklabnik
It's easier for a distro to do dynamic linking for Rust binaries, since they
can mandate a single compiler version across the ecosystem.

~~~
elihu
True. If dynamic linking is all that's needed to get tiny binaries, then
that's probably sufficient from the distro's point of view.

------
Perceptes
Congrats to the team and thank you!

As always, I've updated my Docker image for 1.12. Both the "1.12.0" and
"latest" tags are now 1.12:
[https://hub.docker.com/r/jimmycuadra/rust/](https://hub.docker.com/r/jimmycuadra/rust/)

------
pjmlp
Congratulations on all the good work to everyone!

Trying it out now.

------
timehastoldme
The awesome thing about Rust is that the behemoths don't know about it.

~~~
yitchelle
I don't know. I wish that someone like MS would take this and really spend
some big dollars on it. Mozilla is doing a great job but better collaboration
between the vendors would be extremely beneficial and really increase its
development. That's my hope anyway.

~~~
timehastoldme
I mean, yeah, that would be amazing for the ecosystem. Still! I hope some
small guy comes and makes something awesome with it, esp. w.r.t AI, which Rust
seems sort of perfect for. As much potential as the Amazon-Microsoft-Google-
Facebook-Acme Co. collab has, I'm not convinced that they aren't going to use
it only to build dull chat bots and give us marginally more relevant ads.

