Rust 0.7 Released | Hacker News Reader

Rust 0.7 Released

github.com

172 pointsepenn50 comments

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

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

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.

Where does haskell fit on this paradigm?

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

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.

There is no general zip for every Traversable, though there is one for every Applicative with a suitable instance (like the ZipList wrapper for lists): liftA2 (,)

The reason is that you need to operate on multiple containers at once and that is what Applicative's (<*>) provides, while Traversable only requires Functor and can therefore only traverse one container at a time.

So what Haskell has is just internal iteration, but we have another interface for internal iteration on multiple containers that allows zip to be implemented easily.

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

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

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

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

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

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

Well done sir!

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.

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

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.

Well at least it's not Cygwin...

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

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

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.

You can't really criticize a language for not being supported by a vendors proprietary compiler framework, especially when it targets native. Also, what is wrong with llvm + the rustc?

I don't think anyone was criticizing it so much as saying it presented an obstacle for him.

No, it's a valid complaint: Rust shouldn't require MinGW. The biggest problem here is that Rust doesn't include its own linker, and the moment it cannot use link.exe.

It may be a valid complaint in the sense that not supporting MIPS is a valid complaint. Rust, because of the decisions made in its design, is going to attract developers of low level systems, server-client architectures, etc. If you are developing the type of systems that Rust excels at, wouldn't you also be the type of developer that has no problem developing on and targeting Linux, BSD, MacOS, etc? Or am I missing something? Obviously Servo would be a good use-case, but apart from browsers, nobody targets Windows native software anymore.

(we actually do support MIPS)

So, nobody server-client architectures on Windows?

Have you been inside of one of the many .NET shops around the globe?

Games too. Rust is starting to find a niche in game development, and Windows still rules the roost there.

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

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

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.

Found the list of windows bugs after a bit of searching: https://github.com/mozilla/rust/issues?direction=desc&labels...

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

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

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.

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

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

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

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.

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

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

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

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.

Is it soup yet?

soup?

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

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!

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

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

Who uses this?

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

is rust-azure the rendering backend for servo?

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.

Reply on news.ycombinator.com