
Announcing Rust 1.7 - steveklabnik
http://blog.rust-lang.org/2016/03/02/Rust-1.7.html
======
dikaiosune
Not mentioned in the release, but in the extended release notes:

"Soundness fixes to the interactions between associated types and lifetimes,
specified in RFC 1214, now generate errors for code that violates the new
rules. This is a significant change that is known to break existing code, so
it has emitted warnings for the new error cases since 1.4 to give crate
authors time to adapt."

[https://github.com/rust-
lang/rust/blob/stable/RELEASES.md#co...](https://github.com/rust-
lang/rust/blob/stable/RELEASES.md#compatibility-notes)

I think this is a fantastic example of the even-handed approach in the
compiler stability promises/plans, and it's great to see one of the first real
tests of those promises go so well.

~~~
kibwen
To elaborate, we use a tool called Crater to estimate the potential impact of
breaking changes. It attempts to compile all of the packages on crates.io with
a new version of the compiler to determine any regressions, effectively using
Rust's public package repository as an extended test suite.

Here's Crater's regression report for the linked soundness fix:
[https://gist.github.com/nikomatsakis/2f851e2accfa7ba2830d#ro...](https://gist.github.com/nikomatsakis/2f851e2accfa7ba2830d#root-
regressions-sorted-by-rank) . It detected four root regressions, which means
that there were four packages that were relying on unsound behavior. This
isn't necessarily the full extent of the regressions, however, because if we
ship a compiler that breaks those packages, then any other packages that have
the formerly-unsound packages as dependencies will obviously also break.

Having a concrete list of regressions also allows us to go through the
ecosystem and submit PRs ourselves to bring the affected packages back to
building, which is usually quite easy. Crater is a really, really great tool.

~~~
Terribledactyl
> ...effectively using Rust's public package repository as an extended test
> suite.

This is one of the coolest and most practical things I've read in a while,
seeing what happens to stable(ish) real wild code. So many practical
applications and analytics are coming to mind in many areas.

Thank you. Sparks my interest in Rust again.

~~~
cies
Should also have a look at [http://stackage.org](http://stackage.org) (quite
similar but in Haskell, yet curated -- a "try to compile all" feature also
exists IIRC).

Not sure how much this is used in order to test impact language changes.

~~~
ibotty
It regularly is.

------
kibwen
As mentioned in the OP, Rust really hasn't added any language-level features
since 1.0, but looking forward there were two major features whose RFCs were
accepted this cycle: impl specialization ([https://github.com/rust-
lang/rfcs/pull/1210#issuecomment-187...](https://github.com/rust-
lang/rfcs/pull/1210#issuecomment-187777838)) and the `?` operator
([https://github.com/rust-
lang/rfcs/pull/243#issuecomment-1805...](https://github.com/rust-
lang/rfcs/pull/243#issuecomment-180504407)). The former will keep code from
having to pay a de facto performance penalty for being generic (preliminary
implementation at [https://github.com/rust-
lang/rust/pull/30652](https://github.com/rust-lang/rust/pull/30652)), and the
latter is purely an ergonomic change to make our `Result`-based error handling
more lightweight (preliminary implementation at [https://github.com/rust-
lang/rust/pull/31954](https://github.com/rust-lang/rust/pull/31954)).

I'm personally hoping the latter one manages to get into the beta release for
the next cycle, so that I can use `?` rather than `try!()` for my Rust
tutorial at OSCON this year. :)

~~~
steveklabnik
Well, beta for the _next_ release is already branched; it would be the one
after that, at the earliest.

~~~
kibwen
1.8-beta has branched, yes, but if it stabilizes this cycle it would make it
into 1.9-beta (which would progress to 1.9-stable the week after OSCON), and
our beta releases have proven themselves stable enough that I'm perfectly
happy to use them in tutorials.

~~~
tatterdemalion
I would be surprised if ? were stabilized in the next 6 weeks after how
contentious the RFC was.

~~~
steveklabnik
Yes, I expect it to move more slowly than an immediate stabilization as well.

------
benjismith
Nice! I haven't used rust yet, but I'm really excited about it. I think
Mozilla Research is doing some of the most groundbreaking work in CS lately.

The best part about rust is seeing the equally incredible work being done by
the Servo team. To get a glimpse into some of their best work, here's a video
where they talk about using the GPU to get better performance rendering a DOM
than most native GUI toolkits can achieve on a sophisticated layout:

[https://air.mozilla.org/bay-area-rust-meetup-
february-2016/#...](https://air.mozilla.org/bay-area-rust-meetup-
february-2016/#@25m50s)

~~~
nightpool
Yes, absolutely, if you haven't seen the WebRender video already you need to
watch it. I haven't been this excited about a new technology in a while.

------
BooneJS
I've been devoting a lot of my daylight hours to writing Go, but with Rust at
1.7 and Go at 1.6 I may have to rethink that. ;)

~~~
pferde
But if you go to Rust, your Go skills will start to rust. :)

~~~
aryamaan
And if you go with Go, your Rust skills will go away?

------
mattgodbolt
Also at [http://rust.godbolt.org/](http://rust.godbolt.org/) should you wish
to see the assembly code generated too.

~~~
cpeterso
Thanks. It's interesting to see how the generated code changes across rustc
versions!

~~~
kzrdude
llvm version changes too, so it is also that.

------
Perceptes
Thank you, Rust team! It's like Christmas every six weeks! :D

------
lorenzhs
There was a recent effort by Google to speed up SipHash, it's called
HighwayHash:
[https://github.com/google/highwayhash](https://github.com/google/highwayhash)
\- it includes a compatible, optimized SipHash implementation (1.5x speedup),
a variation on that that is not compatible but similar, SipTreeHash (3x
speedup on top of optimized implementation) and a new algorithm, HighwayHash,
that yields another factor of 2-3. I haven't yet used it myself but it looks
interesting and might be relevant to Rust?

Edited to add that Google's implementation targets Haswell and later (AVX-2),
I don't know about the performance of an implementation that targets older
CPUs which would of course be very relevant for Rust

~~~
kibwen
I believe this is being discussed here: [https://github.com/rust-
lang/rust/issues/29754](https://github.com/rust-lang/rust/issues/29754)

~~~
lorenzhs
Oh nice, I wasn't aware that this is being discussed already. Thanks!

------
SneakerXZ
I wish Rust team invested more into tooling and maybe introduced officially
supported IDE because at the end tooling is more important than the language
itself. Java is not the best language but it obvious choice for many people
because of its IDE integration.

~~~
gnuvince
> maybe introduced officially supported IDE

I would _much_ rather they don't do that and instead offer tools that can
answer IDE-like queries (e.g. "Who calls this function?", "Where is this
identifier defined?", etc.) and let people integrate that into Emacs, Vim,
Atom, and other editors and IDEs. This brings all the communities together and
doesn't dictate one particular tool over all others.

~~~
0xFFC
They have :

[https://www.rust-lang.org/ides.html](https://www.rust-lang.org/ides.html)

>We propose a new tool, an 'oracle' which takes input from the compiler,
maintains a project-wide view of the code and it's type information, and
provides data about the project to IDEs and other tools. The oracle is a long-
running daemon and presents an API via IPC.

Which is great idea. But it is not implemented yet (AFAIK).

personal opinion : Rust with this pace, will be absolutely one of the best
language in term of usage/tools in next 5 year.

------
Kratisto
So I don't know a whole lot about Rust. Can anyone give a summary of why/when
I should use Rust?

~~~
steveklabnik
Someone asked a similar question on /r/rust the other day, here's what I had
to say:

Rust is a programming language. It's a general programming language, so it's
good for a large variety of things. Different people have different reasons
for using Rust. There are three large constituencies, as I see them: systems
programmers, functional programmers, and scripting language programmers.

Before I get into details: all generalizations are false ;)

Systems programmers come to Rust because it's able to do the lowest levels of
software: operating systems, device drivers, stuff like that. Where it
improves on existing systems languages is "safety." The Rust compiler does a
lot of compile-time checking to make sure you don't do things wrong. Existing
languages force you, as the programmer, to double check your work. We have the
compiler double-check your work, and force you to get it right.

Functional programmers see all that static checking, and it feels like home.
But a home where they have significant speed gained. Functional languages can
be fast, but not always C level fast. Rust is. It's easier to get that level
of performance out of Rust.

Scripting language programmers come to Rust for two reasons: the first of
which is to write extensions to their language for speed. You can write a Ruby
gem in Rust, rather than in C. This is useful because this low-level stuff is
not their expertise, and so the extra checks are really nice. Related: we have
a lot of the nice tooling that scripting language folks have come to expect
from their language. No need to write makefiles, we have Cargo. The second is
sort of related, but these checks also mean it's easier to learn low-level
stuff, so if they want to expand their universe, Rust is a nice way to do so.
We're seeing a lot of people for whom Rust is their first systems language.

I didn't know where to put this one, but Rust focuses on a concept called
"zero-cost abstractions." This means that a lot of our features that feel very
high level are extremely efficient. You don't write manual for loops, you se
iterators. You don't deal with pointers directly, but with references.
Structures like Box and Vec do memory management, but you don't need a garbage
collector, and you don't need to manually manage it, but you also don't need
to explicitly call free().

These are very broad strokes. Lots of other people have other reasons too. But
that's some of them.

~~~
BuckRogers
Where do Java, Go and C# programmers fall? Perhaps just more on the order of
more complexly implemented and designed scripting languages? Those three make
up a good swath but systems, functional and scripting don't so map well to
those.

~~~
steveklabnik
You might like [https://llogiq.github.io/2016/02/28/java-
rust.html](https://llogiq.github.io/2016/02/28/java-rust.html)

~~~
llogiq
TL;DR: Java is awesome, Rust is awesome, let's code even more awesome stuff!

------
dominotw
Any ideas how rust's cross compilation compares with golang?

I am amazed with how easy it to cross compile to different platforms supported
by golang. Curious how rust compares.

~~~
steveklabnik
The current situation is "it works, but is not as easy as we'd like." We have
plans underway to make it very trivial, but the needed infrastructure work
isn't quite there yet.

A summary is "every Rust compiler is a cross-compiler, but you need a copy of
the standard library for your target platform available." Getting said copy is
what takes the work. In the future, we want it to be as easy as a call to the
command-line, but for now, [https://github.com/japaric/rust-
cross](https://github.com/japaric/rust-cross) is a good resource.

See also [https://github.com/japaric/rust-
everywhere](https://github.com/japaric/rust-everywhere) , which is very
interesting.

~~~
fabrice_d
I'm maintaining a docker image to cross-compile at
[https://hub.docker.com/r/fabricedesre/rustpi2/](https://hub.docker.com/r/fabricedesre/rustpi2/).
It's Rasberry Pi2 specific since it relies on a tweaked sysroot to link
against OpenSSL and a few other libraries.

The way I'm using it is: docker run --name rustpi2 -v
`pwd`:/home/rustpi2/dev/source -v $HOME/.cargo:/home/rustpi2/.cargo
fabricedesre/rustpi2 cargopi build (cargopi is just equivalent to cargo
--target=armv7-unknown-linux-gnueabihf)

------
StreamBright
Is there any plans to have a stable version and do not introduce breaking
changes after that? Something like 2.x is for Python. I could not find any
reference so far.

~~~
GolDDranks
We already have a stable version. The only breaking changes we are seeing are
soundness-related bugfixes, and crates stop compiling because they rely on
buggy behaviour.

------
jayflux
When will it reach homebrew?

~~~
steveklabnik
Looks like 15 hours ago.

------
desireco42
250K for hello world example... where is this world going to! :)

I am sure it can be trimmed, but we are getting oblivious to common sense a
little. This is system language.

~~~
Manishearth
That 250K is additive, not multiplicative. Hello World, which might be 10K in
C, will be 240K+10K=250K in Rust. A larger program that would be 2M in C would
be 240K+2M in Rust; the significance of that 240K reduces when you write
actual programs (instead of hello world).

The size is due to a statically linked stdlib (also jemalloc, which you can
decide not to use) -- your C program is tiny because your system has a stdlib
it can dynamically link to. Rust can do this too, it's just not the default
since in most cases this additive extra binary size isn't a problem.

Being a systems language does mean we should forgo sensible defaults.

~~~
mystikal
In theory you could tell the compiler to identify and statically link only
those functions needed to make printf work (or a conservative approximation
thereof).

~~~
danieldk
As far as I know, jemalloc is a substantial part of that binary size. See
e.g.:

[https://github.com/japaric/rust-on-
openwrt/issues/1#issuecom...](https://github.com/japaric/rust-on-
openwrt/issues/1#issuecomment-108425440)

[https://github.com/japaric/std-with-cargo#making-rust-
binari...](https://github.com/japaric/std-with-cargo#making-rust-binaries-
smaller)

