Rust 0.12.0 released

https://mail.mozilla.org/pipermail/rust-dev/2014-October/011267.html

by bilalhusain • 12 years ago

281 110 12 years ago

mail.mozilla.org

kibwen12• 12 years ago

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

untothebreach3• 12 years ago

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

mbrubeck• 12 years ago

In cases where a function's input and output have the same lifetime, the lifetime is now inferred. So instead of this:

    fn f<'a>(x: &'a SomeType) -> &'a OtherType

you can now write this:

    fn f(x: &SomeType) -> &OtherType

Same meaning, just more concise syntax.

steveklabnik17• 12 years ago

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

kibwen12• 12 years ago

Basically, after working with lifetimes for so long we realized that a great many functions that take lifetime parameters follow a similar and straightforward pattern. As of this release, we now allow you to omit lifetime parameters entirely for functions that follow this pattern, which is likely the vast majority of functions in your code that previously required such annotations.

The detailed release notes have a more, er, detailed explanation: https://github.com/rust-lang/rust/wiki/Doc-detailed-release-...

saosebastiao• 12 years ago

It has come a long way since I first started using it (0.6 era). Congratulations on the release! I look forward to a future world where I can use it (via Servo) in Firefox, as well as in my Constraint Solver engine, which I hope to reveal for the 2015 Minizinc Challenge.

nnethercote• 12 years ago

MiniZinc! There's a blast from the past... I wrote most of the first few versions of the specification and much of the initial implementation. Good to hear it's still being useful.

Ygg22• 12 years ago

Is there like a what's new in Firefox but for Rust?

frewsxcv• 12 years ago

Yes. Click on the link and scroll down.

blinkingled2• 12 years ago

Does the RFC230 (https://github.com/rust-lang/rfcs/pull/230) removal of green threads give me out of box 1:1 threading or just that std::io uses native threads and the rest has to use green threads only now as an additional outside dependency? Kinda confused given I don't follow Rust all that much.

Really odd that they went with M:N model - if the OS is fast at creating/destroying threads 1:1 is the best model for vast majority of apps.

wycats• 12 years ago

The default is 1:1 threads. If you use `spawn` in Rust, you get a native thread.

pkulak• 12 years ago

Noticeably absent is a really good HTTP library.

M2Ys4U• 12 years ago

Chris Morgan is working on teepee[0] though, so it's coming.

[0] https://github.com/teepee/teepee

Ygg22• 12 years ago

There is also hyper which is used by Servo: https://github.com/hyperium/hyper

jmgrosen• 12 years ago

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

kibwen12• 12 years ago

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

sanderjd3• 12 years ago

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.

doe88• 12 years ago

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

kibwen12• 12 years ago

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

tkellogg• 12 years ago

How long until this hits Homebrew?

cordite• 12 years ago

Dunno, but they already have pre-built installers for nightly.

valarauca1• 12 years ago

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

steveklabnik17• 12 years ago

Nope, homebrew has included Rust for a while: https://github.com/Homebrew/homebrew/blob/master/Library/For...

waxjar• 12 years ago

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

steveklabnik17• 12 years ago

(will merge when the bot finishes and goes green)

https://github.com/Homebrew/homebrew/pull/33060

eslaught• 12 years ago

Is there a Cargo build on Homebrew?

acqq11• 12 years ago

Reading the new Guide:

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.

steveklabnik17• 12 years ago

Currently, there is no default. This is probably changing back. See 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.

acqq11• 12 years ago

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?

thomasahle3• 12 years ago

This is a great example of Rust's practicality and a scientific/empiric mindset to building the language.

Rust sometimes seems like the antithesis to BDFL. I quite like that they experiment, but I'm wondering how this will work out post 1.0.

MichaelGG• 12 years ago

The default seems to be "inferred". That is, 1 + 1i will work, but 1 + 1 is ambiguous. I've just noticed this in use, and don't know what this is officially called. I don't think this will actually be a real annoyance in practice.

kibwen12• 12 years ago

It's just type inference. Rust doesn't do automatic integer coercion on arithmetic operations, so once it knows the type of any of the numbers it can deduce the types of all the rest.

rdtsc• 12 years ago

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.

steveklabnik17• 12 years ago

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.

kibwen12• 12 years ago

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

hugh4life• 12 years ago

I noticed that in the last round of the language shootout benchmarks that rust was significantly behind C++(and I also noticed that this was being addressed on the rust reddit).

I'd like to see more benchmarking done between rust and C++ where there is a solution for each language that is idiomatic or safe while another solution optimizes for performance.

bjz_3• 12 years ago

I think soon should be a time to look at performance. Performance should be close to or better than C++ on average.

The language has been designed from the ground up to compete on this level. Also note that Rust potentially has far greater room for compile time optimizations than C and C++, because the compiler knows far more about lifetimes and ownerships. This can be seen in one of the last items in the release notes:

Stack usage has been optimized with LLVM lifetime annotations.

acqq11• 12 years ago

I thought it won't be more than two times slower. The basic design was supposed to alow the speed of C with the added benefit of safety. But it's much worse:

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

I agree with you, unless the language creators address this the language has much more chance to remain unused.

dbaupp8• 12 years ago

Most of the 'problems' there are Rust programs not micro-optimised to the ridiculous extent of the C ones, e.g. the C ones almost all use SIMD instrinsics or features like OpenMP.

Rust is a new, experimental language and the support for SIMD is still in development, and we still don't have much in the way of data-parallel libraries. The type system has been expressly adjusted to allow for safe data-parallel libraries though, so they will appear.

Also, a few other points:

- Rust allows for opting in to unsafe code (with rules and overhead similar to C), which can be used for performance optimisations. Last time I checked, none of the Rust benchmark programs used any unsafe. (On the other hand, all of the C programs are effectively using `unsafe` code always)

- C is using highly optimised libraries; Rust has zero overhead FFI, and so can easily call into them, but is not for those benchmark (e.g. the pidigits one is just a benchmark of "are you using GMP?", if the Rust was written to use it, there is no reason it would be slower than C)

- The worst offender (reverse-complement) is apparently written without any thought of performance, e.g. it is doing formatted IO for each and every character it emits, rather than writing to an in-memory buffer and dumping that in one go like the C.

In summary, those benchmarks do not reflect the fundamental speeds of the languages, other than the suboptimal SIMD support in Rust.

gnuvince• 12 years ago

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

steveklabnik17• 12 years ago

Thanks! https://github.com/rust-lang/rust-www/pull/64 submitted.

darklajid2• 12 years ago

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_3• 12 years ago

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

darklajid2• 12 years ago

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.

Rust 0.12.0 released

Related Stories