

Rust 0.7 Released - epenn
https://github.com/mozilla/rust/blob/master/RELEASES.txt#

======
kibwen
The "detailed release notes" page: [https://github.com/mozilla/rust/wiki/Doc-
detailed-release-no...](https://github.com/mozilla/rust/wiki/Doc-detailed-
release-notes) (it's actually shorter this time than the brief release notes,
amusingly).

The most exciting user-visible change this time around is almost certainly the
new iterator libraries. See the several links in the detailed release notes
for more context, but this is such a good resource that I can't resist linking
it again here: [http://journal.stuffwithstuff.com/2013/01/13/iteration-
insid...](http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-
out/)

EDIT: a link to the actual release announcement itself:
[http://thread.gmane.org/gmane.comp.lang.rust.devel/4596](http://thread.gmane.org/gmane.comp.lang.rust.devel/4596)

~~~
sanderjd
The post about internal and external iteration is fantastic and definitely
makes a good argument for a language supporting both (which newer versions of
Ruby do, actually), but this part left me scratching my head:

> As far as I can tell, you simply can’t solve [the interleave example
> problem] using internal iterators unless you’re willing to reach for some
> heavy weaponry like threads or continuations.

I must be missing something, because it doesn't seem particularly hard:

    
    
      class Array
        def interleave_each(other)
          self.zip(other).each do | a, b |
            yield a if a
            yield b if b
          end
        end
      end
    

Am I cheating somehow, or have I misunderstood the problem?

Edit: Ah, I see, the problem is that I'm relying on the specific semantics of
lists, which works for the example as written, but not for the general case
(ie. if I have one file and one list).

~~~
TheCoelacanth
You "cheated" by using zip. You can't easily implement zip using only internal
iterators but you easily can using external iterators. If you look at a
slightly different problem that doesn't precisely fit the special case of zip
you'll see the difficulty involved with using internal iterators.

~~~
nimish
Where does haskell fit on this paradigm?

You can derive "internal" iterators using Traversable but it's not like zip is
difficult to implement.

~~~
pcwalton
Haskell typically uses internal iterators, but because it's lazy many
composition strategies are more straightforward. Rust is strict, however, so
the same techniques don't apply.

------
paulkoer
Has it been decided yet if garbage collection should be moved out of the core
and only be provided as a library? If memory serves me right there was some
discussion on this shortly after the 0.6 release [1][2].

[1] [http://pcwalton.github.io/blog/2013/06/02/removing-
garbage-c...](http://pcwalton.github.io/blog/2013/06/02/removing-garbage-
collection-from-the-rust-language/)

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

~~~
kibwen
Consensus is leaning towards moving it out into a library. The only undecided
thing at this point appears to be the fate of the @ symbol, e.g. whether it
should remain as sugar for user-provided pointer types (which includes types
in the stdlib).

~~~
moomin
So @ would mean "something that implements the pointer trait"?

------
cpeterso
The Rust documentation is a list of modules, but I think a cross-reference
with a list of all traits declared in all modules would be very useful.
Developers, particularly people writing libraries, would have a big "to-do"
list of all the traits their new types could implement.

~~~
cmrx64
Hi! I'm working on the new rustdoc (the current one is horribly outdated and
all-around crappy). Any other feature requests? I'm tracking them at
[https://github.com/mozilla/rust/wiki/Bikeshed-
rustdoc](https://github.com/mozilla/rust/wiki/Bikeshed-rustdoc)

------
DASD
Is Rust always going to require MinGW on Windows? I'm very interested in Rust
but this is a stopper for me if Windows executables are going to need this.

~~~
asb
It is the intention to support MSVC:
[https://github.com/mozilla/rust/issues/1768](https://github.com/mozilla/rust/issues/1768)

~~~
kibwen
Note that that bug is filed under the "backwards compatible" milestone, which
is the _absolute minimum_ for a 1.0 release. Barring drastic circumstances,
you should assume that MSVC support will land before then.

However, Rust really needs Windows-savvy developers! If you can help, please
do.

~~~
shadowfox
Found the list of windows bugs after a bit of searching:
[https://github.com/mozilla/rust/issues?direction=desc&labels...](https://github.com/mozilla/rust/issues?direction=desc&labels=A-windows&page=1&sort=created&state=open)

Seems like there are a few straightforward "fixables" in there.

------
tkellogg
It says

    
    
        `Option<~T>` is now represented as a nullable pointer.
    

Does that mean they _introduced_ more prevalent nulls into the language? that
seems like a shockingly bad choice

~~~
kibwen
No, it means that _at runtime_ the representation of `Option<~T>` is simply a
nullable pointer (this is also how borrowed pointers are represented at
runtime, i.e. with no overhead whatsoever compared to C-style pointers). It's
simply a perfectly-safe memory optimization (the language leaves the runtime
representation of enums (of which Option is one) deliberately unspecified so
that these types of optimizations can be made). It doesn't make Rust any less
safe, as the language itself still has no notion of null pointers.

------
moomin
I like that the iterator trait has a thread-safe design. C#'s is a pain in the
neck: having MoveMext and Current as separate methods was a bad idea.

~~~
kibwen
That was never a concern; it would take signficantly _more_ work to make
iterators non-thread-safe. Welcome to Rust. :)

EDIT: And if you're referring to the way that our iterators automatically
guarantee that iterator invalidation just can't happen, well, that's simply
how borrowed pointers work! No extra effort required (not that borrowed
pointers are the easiest thing to grok in the first place, mind you...).

~~~
moomin
To clarify, having advance return the result means the design can be used to
read from an external queue on multiple threads. C#'s IEnumerable can't do
this, because the interface assumes only one consumer.

(Edit: I should point out C# is not the only platform that gets this wrong.
C++/STL has the same design.)

------
marshray
Is it soup yet?

~~~
bjz_
soup?

~~~
mindcrime
It's a figure of speech... asking "is it soup yet?" basically means "is it
done yet?" I haven't met many people who use that particular expression, but I
had an old boss who was from the Pittsburgh, PA, area who used that all the
time. Apparently it was inspired by a 1970's era commercial for Lipton
soup.[1]

[1]:
[http://www.urbandictionary.com/define.php?term=Is+it+soup+ye...](http://www.urbandictionary.com/define.php?term=Is+it+soup+yet%3F&defid=2965736)

~~~
marshray
You kids today, you don't know how good you have it. Back in my day we didn't
have Internet memes, we had _television_. Three whole channels of it!

~~~
mindcrime
We only had two channels... "off" and a channel full of snowy looking stuff
that made a noise like
kkkzzzzzzsshshshszzssshshshzzssshhshszzzsshshshzzsshshshszzzsshhhh...

~~~
Flenser
Luxury! we had to make the noise ourselves...

------
DonnyV
Who uses this?

~~~
pcwalton
It's not production-ready yet. However, we're using it for Servo, and there
are various projects using Rust.

Here's a page with some of the projects I know off the top of my head:
[https://github.com/mozilla/rust/wiki/Projects-using-
Rust](https://github.com/mozilla/rust/wiki/Projects-using-Rust)

~~~
zokier
is rust-azure the rendering backend for servo?

~~~
pcwalton
Yes, Rust uses Azure as the rendering backend for all content. Azure, in turn,
wraps Skia, Core Graphics, Direct3D, and Cairo/Pixman. It allows us to work
with the native drawing backend on each platform with one set of rendering
code.

