
Rust 0.12.0 released - bilalhusain
https://mail.mozilla.org/pipermail/rust-dev/2014-October/011267.html
======
kibwen
I'm very excited at the progress in this release. In particular I'm thrilled
at the ongoing focus on ergonomics and overall developer experience, what with
the push for quality documentation (brand-new tutorials, code examples for all
library functions, and API stability markers) and the rapid maturation of
Cargo. Also, lifetime elision and `where` clauses have done wonders in
reducing the horror that has historically plagued Rust function signatures.

There's also been tons of progress toward the last features that are blocking
the 1.0 release ([http://blog.rust-
lang.org/2014/09/15/Rust-1.0.html](http://blog.rust-
lang.org/2014/09/15/Rust-1.0.html)). The long-awaited work on dynamically-
sized types is now partially complete, and the only two remaining big hurdles
that I can think of are closure reform and trait coherence reform. Onward to
stability!

~~~
untothebreach
excuse my ignorance, but what exactly does 'lifetime elision' mean?

~~~
steveklabnik
Part of Rust's ownership system are 'lifetimes.' Without getting into the
details, they're an annotation you occasionally add to code in certain
situations. Like these two:

    
    
        fn get_mut<'a>(&'a mut self) -> &'a mut T;
        fn print<'a>(s: &'a str);
    

The 'a parts are the lifetime annotations.

We used to have a single inference rule for when you didn't need to write the
annotation. With RFC 39[1], we added two more. These two extra inference rules
removed 87% of the existing annotations, giving you this instead:

    
    
        fn get_mut(&mut self) -> &mut T;
        fn print(s: &str);
    

This is a pretty huge readability win.

1: [https://github.com/rust-
lang/rfcs/blob/master/active/0039-li...](https://github.com/rust-
lang/rfcs/blob/master/active/0039-lifetime-elision.md)

~~~
haberman
What kind of cases do you still need to write explicit lifetimes?

~~~
steveklabnik
I actually haven't had to since elision was implemented, so I can't give you a
good rule of thumb from experience. Here's an overview of how the rules
applied to the standard library at the time they were implemented, which is
where the percentage came from:
[https://gist.github.com/aturon/da49a6d00099fdb0e861](https://gist.github.com/aturon/da49a6d00099fdb0e861)

------
darklajid
From someone that sucks at C (learned a bit here and there a decade ago and
never used it) and recently started looking into 'system' languages again:

\- The community was very friendly, although my questions probably were more
on the 'RTFM' side of things

\- The rust compiler is amazing. The error messages it provides are clear and
helpful, often including potential spelling corrections and/or repeating the
part of the code that causes trouble, closing with a suggestion to fix that.

It's not quite magic, but really impressive and helped me a lot to get
started. Being a Windows dev by day I do bemoan the fact that this platform is
a bit .. behind, but I'm actively pursuing a sideproject based on rust (on
Windows) atm.

~~~
bjz_
> The rust compiler is amazing. The error messages it provides are clear and
> helpful

I'm sure that Clang inspired the great error messages - it sets a very high
bar for new compilers (and old - GCC is still catching up).

> Being a Windows dev by day I do bemoan the fact that this platform is a bit
> .. behind

I'm sure that once 1.0 is released there will be a greater effort to make the
Windows experience more seamless. This will be extremely important if we want
to convince more game developers to give Rust a go. Have you seen
[https://github.com/PistonDevelopers/VisualRust/](https://github.com/PistonDevelopers/VisualRust/)?

~~~
darklajid
Nope, haven't seen VisualRust before. Thanks.

That said, IDE support isn't exactly what I was referring to.

\- you need to install mingw separately and there are lots of reports about
conflicts with other software that might bundle a different version of mingw

\- installing cargo is weird (so far .. I failed and don't use it)

And even with my first baby-steps (i.e. doing basically nothing of value) I
discovered some limitations, one being that you cannot create a DLL that
exports an unmangled entry point - for stdcall (other calling conventions
don't have that issue and follow #[no_mangle] or #[export_name="foo"].

BUT that's really not a huge deal for me. Just a bumpy road at times.

------
rdtsc
All this is good stuff.

I think soon should be a time to look at performance. Performance should be
close to or better than C++ on average. We know about "the root of all evil".
But, if there is going to be any large uptake from those using C++ currently
(and I imagine a lot of those developers are concerned about performance,
memory usage etc), Rust simply has to compete on performance as well.

Go in a way started that path. The whole "systems language" re-interpretation
and all. But it never quite became the systems systems language. It can't
quite eat C's and C++'s lunch figuratively speaking.

Rust might be able to do it. But regardless of concurrency, type safety and
other features if it cannot be fast enough it will have a hard time.

~~~
steveklabnik
We already do pay attention to performance. In general, Rust should already be
in the same league as C or C++. Please open issues if you find something that
isn't.

~~~
kibwen
And even more important than current benchmark numbers is that the language is
explicitly designed to be optimizable, and takes the idea of "zero-cost
abstractions" seriously. I can count on two fingers the number of places where
we impose dynamic checks by default in the name of safety, and one of those
can be unsafely turned off and the other can be safely disabled with proper
code structuring.

(Theoretically we can also leverage Rust's ownership rules to automatically
generate aliasing information. When implemented this should be an across-the-
board speed boost for all Rust code in existence, in a way that C and C++
compilers can only dream of.)

~~~
tpush
Would there also be a performance boost compared to C code which properly uses
'restrict'?

~~~
kibwen
The underlying compiler backend would use the same alias optimization pass for
both Rust and C. Rust's advantages here are that all Rust code is
automatically eligible for such optimization without the programmer having to
do any work at all, and whereas a programmer can get `restrict` usage wrong
(or alternately fail to have the confidence that a given pointer is truly
unaliasable), the Rust compiler has perfect information.

To be fair, there are also optimizations that C can do that Rust can't, often
resulting from C's undefined behavior.

~~~
tpush
Thanks for the information! Looking very much forward to rust 1.0.

------
doe88
Very good idea these _release notes_ [1]. In a perfect world it should be even
more detailed a bit like _What 's new in Python x.x_ notes.

Maybe by giving the gist of an RFC through an example or an high-level
description before linking to it, because there are some RFCs a bit
overwhelming I think, more theoritical than illustrated with examples.

[1] [https://github.com/rust-lang/rust/wiki/Doc-detailed-
release-...](https://github.com/rust-lang/rust/wiki/Doc-detailed-release-
notes)

~~~
kibwen
Because it's easy to miss, note that there is a longer list of summarized
changes below the links in the OP, also reproduced in this file:
[https://github.com/rust-
lang/rust/blob/master/RELEASES.md](https://github.com/rust-
lang/rust/blob/master/RELEASES.md)

------
jmgrosen
...and as usual no one will actually use it ;)

(Because of the nightlies, I mean -- the language itself even I use!)

But really, is there any reason to have these "releases" that almost no ones
uses, or is it just to have a concrete changelog every once in a while?

~~~
kibwen
Actually, I've heard from at least one person that the code that they wrote
for 0.11 _didn 't break_ when upgrading to 0.12! A milestone in Rust history!!

As we approach 1.0, these last few snapshot releases will become more and more
valuable since the reduced frequency of breakage means that they will be more
representative of the final language. The fact that people feel compelled to
develop against nightlies is a bug, not a feature! :)

~~~
sanderjd
I recently received a pull request on a library that I hadn't updated in about
6 months, and was _astonished_ how few changes it needed! Very exciting times.

------
acqq
Reading the new Guide:

[http://doc.rust-lang.org/guide.html](http://doc.rust-lang.org/guide.html)

"The first thing we'll learn about are 'variable bindings.' They look like
this:

    
    
        let x = 5i;

"

And so on: "let (x, y) = (1i, 2i); let x = 5i; x = 10i; "

I had to double check if the default (when the i is not written) is something
else than int. It is confusing.

~~~
steveklabnik
Currently, there is no default. This is probably changing back. See
[https://github.com/rust-lang/rust/issues/15526](https://github.com/rust-
lang/rust/issues/15526) and the associated issues.

The TL;DR is this: not having a default type makes you consider which size to
choose. This is generally good. But there are two good cases in which having a
default helps a lot: examples and tests. Both of these are small, and don't
really care about the details.

In real code, inference means you can often not get away with annotating
numbers, because the type is inferred. But in these two cases, there often
isn't something to do the inference.

Long ago, there was fallback, and then it was removed, and now we're
considering putting it back. This is a great example of Rust's practicality
and a scientific/empiric mindset to building the language.

~~~
acqq
Thanks! I support having the most convenient defaults. Not only for integers,
but for other stuff too. Is there a default now for 3.33? Is there a default
for "string in quotes"? If there is, integers should be the default too.

I believe that everybody can invent as much red tape as he wants, the hard
thing is making it concise and effective for the everyday use, not for the
writers of compiler.

Digressing, were there any discussions about using var like in Swift (instead
of let mut)? What is the rationale for not making that more minimalistic?

~~~
steveklabnik
The thing is, for floats there's a default that makes sense. For strings,
there's a default that makes sense.

Integers, on the other hand, are harder. You _probably_ want i32, even on 64
bit machines, but then an i32 can't index an array, so for integers used that
way, you want a machine-sized integer.

~~~
acqq
> for floats there's a default that makes sense

Really? In C I use both doubles and floats all the time.

> i32 can't index an array

Why? Is it because Rust would use less than 32 bits for indexes on some
platforms? And how should then the indexes for arrays be written?

You have really a hard job, when such basic things change?

~~~
steveklabnik
Unless you need the extra precision, using a float makes more sense than a
double.

But with integers, it's different. It's not so much that an i32 _can't_ index
an array, but that it _might not be able to_. On a 64 bit machine, you could
have a very large array that's bigger than an i32 in size.

~~~
acqq
> Unless you need the extra precision, using a float makes more sense than a
> double.

No. Floats are OK for big storage, but for a lot of uses you want to make all
the intermediate calculations in doubles and only when storing the results to
convert to floats again. See

[https://news.ycombinator.com/item?id=8434128](https://news.ycombinator.com/item?id=8434128)

(at the moment top of the front page) where people have problem with Intel
using 66 bits mantissa internally for the input of 53 bits (double!). You
don't want to have partial results as floats unless you're doing graphics and
simple calculations where you need much less bits. You'd would never like to
calculate a bridge construction with floats, even if the needed parts would at
the end be written with only 4 digits.

~~~
steveklabnik
That's what I intended as part of 'if you need the precision.' You're
absolutely right that even if the beginning and end are floats, you may want
to do the intermediate calculations as a double.

~~~
acqq
Therefore it's often important to have fp constants with as much bits as
possible. But there are exceptions again: unless you use them to initialize
float arrays etc.

Regarding indexes for arrays, there are typical uses that should be
recognized: if I write a[ 1 ] I'd like to be able to address the element 1. If
I write a[ 0xffffffffffff ] it's also clear it's more than 32 bits.

~~~
steveklabnik
Right. There's tons of reasonable choices here. Which is why Rust currently
has no defaults, and is why you need to write 5i today.

This whole topic is very much still under discussion. While many want
defaults, what they default to is still a question. And there's a sizable
group that doesn't want any default at all.

~~~
nophilosoraptor
Floats are like 16-bit shorts. Useless.

There is little performance advantage to using a 32-bit float. Their precision
is low enough that you can't do anything useful without risking the
correctness of your program.

They are, like shorts, an artefact of the past. Unlike shorts, their
limitations are not within the intuition of the average programmer, which
leads to widespread abuse and bugs.

Kill them before it's too late.

~~~
yaantc
This is too brutal, you have to consider the application domain. For physics
simulations I would agree with you. For signal processing or graphics
applications float is usually perfectly fine (and even overkill for many DSP
applications).

People mentioned the cache efficiency gain with floats, and that is already
relevant to rust. If in the future maybe rust could be used for GPGPU, then
the difference between float and double often becomes even more dramatic. You
definitely want to keep float support for this.

~~~
kibwen
Packets for networked multiplayer games are another place where half-precision
floats are acceptable:
[http://www.gamasutra.com/blogs/MarkMennell/20140929/226628/M...](http://www.gamasutra.com/blogs/MarkMennell/20140929/226628/Making_FastPaced_Multiplayer_Networked_Games_is_Hard.php)

(Though it must be said that Rust doesn't actually have a 16-bit float type at
all.)

------
gnuvince
Quick note: as of 09-Oct-2014 at 18:20 EDT, the page [http://www.rust-
lang.org/install.html](http://www.rust-lang.org/install.html) shows the
release date of 0.12 as July 2, 2014.

~~~
steveklabnik
Thanks! [https://github.com/rust-lang/rust-
www/pull/64](https://github.com/rust-lang/rust-www/pull/64) submitted.

------
tkellogg
How long until this hits Homebrew?

~~~
valarauca1
Likely the 1.0 release. Most Linux distros are holding off shipping rust until
the 1.0 release.

~~~
waxjar
Homebrew has formulas for Rust. I installed Rust 0.11 yesterday :)

~~~
sigzero
0.12.0 is up now.

