Rust 0.7 Released

https://github.com/mozilla/rust/blob/master/RELEASES.txt#

by epenn • 13 years ago

172 50 13 years ago

DASD2• 13 years ago

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.

kmicklas• 13 years ago

Well at least it's not Cygwin...

marshray4• 13 years ago

Do the executables require MinGw to run or just to build?

EDIT: DASD above says "all Rust executables require a MinGW installation at runtime."

pbsd• 13 years ago

Both, last I checked. Plus it requires a very specific version of the gcc runtime to be installed (4.5 I think), that doesn't come bundled with the installer.

asb• 13 years ago

It is the intention to support MSVC: https://github.com/mozilla/rust/issues/1768

DASD2• 13 years ago

Thank you. For those interested in the original FAQ(https://github.com/mozilla/rust/wiki/Doc-language-FAQ) and hence my reason for asking...

"Does it run on Windows?

Yes. All development happens in lock-step on all 3 target platforms. Using MinGW, not Cygwin. Note that the windows implementation currently has some limitations: in particular tasks cannot unwind on windows, and all Rust executables require a MinGW installation at runtime."

kibwen5• 13 years ago

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.

marshray4• 13 years ago

Is it soup yet?

bjz_• 13 years ago

soup?

mindcrime2• 13 years ago

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

kibwen5• 13 years ago

The "detailed release notes" page: https://github.com/mozilla/rust/wiki/Doc-detailed-release-no... (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...

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

sanderjd• 13 years ago

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• 13 years ago

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.

paulkoer• 13 years ago

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

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

kibwen5• 13 years ago

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

moomin5• 13 years ago

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

moomin5• 13 years ago

I'm hoping the "coerce to borrowed" functionality will work with user defined pointers. Maybe via a trait?

dbaupp• 13 years ago

That's the plan: make library defined pointer types first class.

scopendo• 13 years ago

If memory serves you right, then it shouldn't matter :)

zanny2• 13 years ago

Well done sir!

tkellogg• 13 years ago

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

kibwen5• 13 years ago

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.

duaneb• 13 years ago

I would guess that the implementation was specialized but the language semantics (including safety from null derefs) would not change.

pcwalton6• 13 years ago

It's just an implementation optimization. The interface didn't change.

MichaelGG• 13 years ago

FWIW, F# has a similar option. You can make one case in a discriminated union be represented by null. This is a handy perf optimization as you can check that case by comparing to null (instead of a global singleton or allocated object).

moomin5• 13 years ago

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.

kibwen5• 13 years ago

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

moomin5• 13 years ago

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

ajanuary• 13 years ago

The problem C# has is that wrapping every iteration result in a container would make iteration ever more expensive than it currently is.

The Option type in Rust is incredibly cheap compared to the equivalent struct or class in C#.

moomin5• 13 years ago

OK, I'll happily admit to a lack of deep knowledge here, but returning a struct of <success, value> doesn't strike me as less expensive than doing two function calls to get the same data. I'm more inclined to suspect they didn't do it that way because C#1 didn't have generics.

I'll happily admit Rust's more efficient, though.

DonnyV• 13 years ago

Who uses this?

pcwalton6• 13 years ago

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

zokier• 13 years ago

is rust-azure the rendering backend for servo?

cpeterso• 13 years ago

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.

cmrx642• 13 years ago

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

Rust 0.7 Released

Related Stories