
Rust 0.10 released - asb
https://mail.mozilla.org/pipermail/rust-dev/2014-April/009387.html
======
lifthrasiir
Highlights (no particular order, partially reflects my personal interests):

\- Managed (GC-ed) pointers are moved to the standard library. There is no
special syntax (formerly `@`) nor special header (for vectors containing
managed pointers) required.

\- Special treatments on `str` and `[T]` vectors are being generalized
("Dynamically Sized Types").

\- Lifetimes of temporary expressions have changed in somewhat more intuitive
way.

\- Syntax extensions are now exportable, documentable and much more flexible
("procedural macro").

\- Language simplifications: `do` syntactic sugar is removed, `priv` is now
default, no trait bounds by default (e.g. formerly `:Send` was implied for
`~Trait`).

\- The smart pointer usage has been improved with new `Deref` and `DerefMut`
traits.

\- There are now many auxiliary standard libraries instead of a single `extra`
library.

\- Usual library fixes, redesigns and influx took place. Most prominent change
is an introduction of growable vector type, `Vec<T>`, which subsumes the
original `~[T]` type.

\- Rustpkg is gone, long live Cargo! Rustc has also combined many related
options into umbrella flags (e.g. `-C`).

As prior point releases of Rust did, Rust 0.10 does not represent a
significant milestone. It is always recommended to use the most recent
development version (master) of Rust, but it had been a great undertaking to
compile Rust from scratch. From 0.10 onwards, however, there are official
nightly versions [1] and brave souls can play with master more conveniently
now. (They are currently not signed yet, so take that in mind.)

[1] [https://mail.mozilla.org/pipermail/rust-
dev/2014-March/00922...](https://mail.mozilla.org/pipermail/rust-
dev/2014-March/009223.html)

~~~
kibwen

      > Managed (GC-ed) pointers are moved to the standard library.
    

_Most_ uses of the old managed pointer scheme have been excised, but not all
just yet (though we have people working on it with great vigor and tireless
devotion). They're behind a feature flag though, so it's not possible to use
them by accident.

For example, note that the replacement type in question, std::gc::Gc, is still
internally backed by the old managed pointers, although this will not be the
case once we finally implement a proper garbage collector. And even then if
you really need multiple owners of a single value we'd really prefer that you
use our reference-counted pointer (std::rc::Rc) instead, along with weak
pointers (std::rc::Weak) if your data has cycles. Reference counting in Rust
is generally surprisingly cheap, since the refcount only gets bumped if you
explicitly clone the pointer; otherwise the pointer simply gets passed around
as an owned value.

------
kibwen
Congrats to all developers on the release! Here's a selection of some of my
personal favorite changes in this release cycle:

* Automatically-generated nightly binaries for all first-tier platforms [1]

* Switching the default hashmap over to Robin Hood hashing [2]

* Turning on native threading by default, in lieu of the green thread runtime [3]

* The removal of conditions in favor of a standardized type for returning I/O results, which will (by default) generate a warning if the result is ignored [4]

* The extension of the lifetimes of temporary values, which should greatly reduce the occasions where you have to assign a name to a temporary result in an effort to please the compiler [5] [6]

And if you're thrown by the idea that version 0.10 follows version 0.9, know
that _I_ voted for 0.A (alas). 1.0 is still expected for later this year,
though no promises!

Remember, Rust 1.0 is _not_ the milestone when the language is finished, but
rather the milestone when backwards-incompatible changes to the language will
no longer be made. See the "backcompat-lang" tag on the issue tracker for a
list of outstanding blockers. [7]

[1] [https://mail.mozilla.org/pipermail/rust-
dev/2014-March/00922...](https://mail.mozilla.org/pipermail/rust-
dev/2014-March/009223.html)

[2]
[https://github.com/mozilla/rust/pull/12081](https://github.com/mozilla/rust/pull/12081)

[3]
[https://github.com/mozilla/rust/pull/12833](https://github.com/mozilla/rust/pull/12833)

[4] [https://mail.mozilla.org/pipermail/rust-
dev/2014-February/00...](https://mail.mozilla.org/pipermail/rust-
dev/2014-February/008505.html)

[5]
[http://smallcultfollowing.com/babysteps/blog/2014/01/09/rval...](http://smallcultfollowing.com/babysteps/blog/2014/01/09/rvalue-
lifetimes-in-rust/)

[6]
[https://github.com/mozilla/rust/pull/11585](https://github.com/mozilla/rust/pull/11585)

[7]
[https://github.com/mozilla/rust/issues?direction=asc&labels=...](https://github.com/mozilla/rust/issues?direction=asc&labels=P-backcompat-
lang&milestone=20&sort=created&state=open)

~~~
jksmith
>* Turning on native threading by default, in lieu of the green thread runtime
[3]

Curious about rationale for this. Have details?

~~~
kibwen
The switch was inspired by this mailing list thread back in November:
[http://thread.gmane.org/gmane.comp.lang.rust.devel/6479](http://thread.gmane.org/gmane.comp.lang.rust.devel/6479)

~~~
twic
A select quote:

> Memory mapped I/O is also an incredibly important feature for I/O
> performance, and there's almost no reason to use traditional I/O on 64-bit.
> However, it's a no-go with M:N scheduling because the page faults block the
> thread.

This is more or less why Java switched to native threads a decade and a half
ago. Although in that case, it was page faults from hitting swap rather than
memory-mapped IO. And in both cases, compatibility with existing native code
which makes blocking system calls was also a consideration. It's reassuring
that Rust is following a path well-worn by other serious languages.

Now it's just a question of waiting for Go and Node to do the same.

~~~
yepguy
Google has been pushing for performance improvements in native threads for a
similar reason. If that's successful, I think the plan is for Go to switch
too, but I can't find any links about it atm.

~~~
fmstephe
[https://www.youtube.com/watch?v=KXuZi9aeGTw](https://www.youtube.com/watch?v=KXuZi9aeGTw)

That might be the talk you are thinking about. I am keeping an eye on this. If
we can have our cake and eat too w.r.t green threads and performance I will be
very happy.

------
dmunoz
I must have misunderstood what was changing in rust re: pointer types. My
understanding was that managed boxes using the sigil @ were being removed, and
GC moved to the standard library std::rc::Rc.

When I last read the tutorial, I read master instead of 0.9, and thought that
the existence of the managed box in the tutorial was only due to it not yet
being updated. But the 0.10 tutorial retains references to managed boxes using
thee sigil @.

Is the tutorial not yet updated? Did @ not get removed from the core in time
for 0.10? Or did I just misunderstand what is actually happening?

~~~
eridius
Most likely the tutorial didn't get updated. It doesn't get a lot of love.

kibwen already posted[1] more details about @ in Rust 0.10, but the short of
it is, @ still exists but is gated behind a feature flag. Code that uses it is
still being updated. The functionally equivalent replacement is std::gc::Gc,
but you should consider std::rc::Rc for reference counting instead (which
supports weak references).

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

~~~
dmunoz
> Most likely the tutorial didn't get updated. It doesn't get a lot of love.

Ah, that's a shame. I actually just mentioned the tutorial as an awesome
resource in another comment.

Maybe my understanding of the Rust language isn't as good as I thought it was,
as most of it comes from reading the tutorial and the related guides linked at
the end.

I'm a big fan of high quality documentation, and I assumed since the current
tutorial was so well written, it was being handled actively already. This is
actually one area I would love to step up and help Rust with. I've previously
gone so far as to read some of the compiler implementation, but my experience
with programming languages is still stuck in the interpreters stage, so it
didn't get very far.

~~~
cmrx64
The _guides_ are up-to-date and maintained, but the tutorial itself is long,
bulky, and ill-maintained. There is a contractor working on rewriting it.

------
ripter
Is it safe to start learning and using Rust for hobby projects or should I
wait until 1.0?

~~~
derekchiang
Yes, lots of people have started using Rust for hobby projects [0] and their
feedback has been invaluable to the development of the language.

[0] [http://rust-ci.org/projects/](http://rust-ci.org/projects/)

~~~
hkphooey
Will there be any impact on Rust due to Brendan Eich quitting Mozilla?

How much involvement did he have on the project?

~~~
pcwalton
Brian Anderson said it better than I could:

Brendan's resignation as CEO will have no effect on Rust or Servo.

Many people at all levels of the organization are huge supporters of Rust,
Servo, and Mozilla Research in general.

------
sixbrx
So how easy would it be to use Rust to compile libraries to be called from
non-Rust systems?

I've seen reference to using #[start] and #[no_std] but it wasn't clear with
the latter just how much of "std" I'd be giving up? Hopefully that would mean
just giving up task spawning and inter-task communication (ok), or would it be
everything under the std namespace (not so ok)?

Making this easy would be an easy win to get Rust into active use
incrementally. Rust would for example be able to do heavy lifting in
computations with Python/Cython providing a web front end dispatcher.

~~~
ben0x539
If you just link some rust code into a C program without #[no_std], once you
call anything that makes use of the runtime, it will abort with a lovecraftian
error message and a stack trace because it asserts that the runtime exists and
has placed some info into thread-local storage. It'll run until then, though!

If you'll only call into rust from a single C-created thread, you could start
that thread through a shim that starts up the rust runtime. Rust code can then
spawn its own threads in there and all of std might just work.

~~~
dbaupp
I don't think #[no_std] has any effect here, other that guaranteeing that know
runtime-using functions are called (by not linking in any runtime at all).

I believe you can also just start runtimes in each call into Rust. Obviously
it won't be particularly efficient.

~~~
ben0x539
That's what I meant re: no_std, yeah.

Would it be possible to lazily start libnative if a call into the runtime is
made but there's none there, but then keep it running for that thread for
subsequent calls?

~~~
dbaupp
Maybe? The current design is starting a runtime is a blocking call, though,
i.e. I think you'd call `native::run`[1] and run anything needing a runtime
inside that (I haven't experimented with this part of our FFI in detail).

[1]: [http://static.rust-
lang.org/doc/master/native/fn.run.html](http://static.rust-
lang.org/doc/master/native/fn.run.html)

------
swah
I love that the Install button gave me an .exe directly - has it always been
like that? I don't remember it being this easy the first time I looked at
Rust. Kudos.

~~~
swah
Oh well it isn't that easy:

    
    
        C:\Users\swah>rustc first.rust
        error: could not exec the linker `gcc`: file not found
        error: aborting due to previous error

------
veeti
What resources would you recommend for learning Rust? There's the official
tutorial but I have to admit that the later parts of it go over my head a
little bit.

~~~
pcwalton
Rust for Rubyists is a great resource I can vouch for (not just for Rubyists):
[http://www.rustforrubyists.com/](http://www.rustforrubyists.com/)

~~~
maxiepoo
I was disappointed in how little detail this went into on the different
pointer types and how/when to use each one. IIRC, it doesn't even mention
lifetimes, which are the feature that's currently stopping me from writing any
rust code (because I don't know how to fix lifetime problems).

~~~
b0b_d0e
As far as fixing lifetime errors is concerned, I would recommend breaking your
code down into a simpler form so that you can look at the lifetimes from a
broader perspective. If you have a simple test case that mimics the same error
that your main program has and you still can't solve it, you can simply make a
gist for it and ask on the IRC and they usually are able to point out the
error. In my experience with lifetime errors, doing it in this method
sometimes reveals the simple error I was over looking, or in other cases after
asking on IRC I learn something new about lifetimes.

------
krick
Maybe somewhat rude question, but how close to being "ready" Rust is? I mean,
should I start using it already if not only for the sake of language itself?
How stable is it now? How much it will probably change 'till 1.0? How soon it
can be expected to be "production ready"?

~~~
renox
> how close to being "ready" Rust is?

I think that this depends on your expectations, I was quite disappointed to
find that there isn't a clean way to make 'unit types' (second, millisecond,
meters, etc) in Rust..

I wouldn't use Rust for anything but toy project..

~~~
wfraser
> there isn't a clean way to make 'unit types' (second, millisecond, meters,
> etc) in Rust..

Actually, there's this bit on Tuple Structs[1] in the tutorial:

> Types like this can be useful to differentiate between data that have the
> same underlying type but must be used in different ways.
    
    
      struct Inches(int);
      struct Centimeters(int);
    

[1] [http://static.rust-
lang.org/doc/master/tutorial.html#tuple-s...](http://static.rust-
lang.org/doc/master/tutorial.html#tuple-structs)

------
glenjamin
I've seen it stated a few times that after Rust 1.0 there will be no more
backwards compatible changes.

Does that mean _ever_ , or just that it'll be stable for some time before
people start considering a 2.0 to try and fix whatever warts are discovered
from wider usage of 1.0+ ?

~~~
kibwen
It certainly doesn't necessarily mean _ever_. Who even knows who will be
leading the project ten years from now! But it _does_ mean that it will be
quite a while before the hypothetical 2.0 where we could consider breaking
backwards compatibility. How long "quite a while" will turn out to be, I can't
say. But it will certainly be an improvement over the current situation, where
the language breaks about once a week. :)

------
Dewie
Wait, I don't understand these version numbers. Wasn't the previous release
0.9? I was expecting the new release to be 1.0, or 0.91, or something like
that. Maybe this is standard practice for all I know.

~~~
kibwen
Rust uses semantic versioning ([http://semver.org/](http://semver.org/)). The
number after the dot is simply a minor version revision, and can increment
without bound.

A 1.0 release of Rust is targeted for later this year. There will be at least
one more minor version (0.11), and possibly more, before that point.

~~~
yepguy
Unfortunately Rust is not actually using semver, which I always found
confusing because they seem to be in support of it, and they even include a
semver library in the core distribution. If they were following semver, this
release would be version 0.10.0 (notice the patch version).

The point of semver is to stick to a standard, instead of every project
deviating from common practice in subtly incompatible ways.

~~~
Tuna-Fish
> If they were following semver, this release would be version 0.10.0 (notice
> the patch version).

Actually, since they are doing backwards incompatible changes in every
release, this version would be more like 10.0.0.

They are deviating from semver for now, I hope they get on it properly for
1.0.0 and beyond.

~~~
yepguy
You are allowed to make breaking changes at any time if your major version is
zero.

~~~
mcguire
Right, because the semver "standard" is inconsistent in that particular way.

