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...
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.
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].
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).
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.
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.
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.
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."
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?
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.
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.
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).
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.)
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.
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]
We only had two channels... "off" and a channel full of snowy looking stuff that made a noise like kkkzzzzzzsshshshszzssshshshzzssshhshszzzsshshshzzsshshshszzzsshhhh...
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.
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