Re:Rust 0.12.0 released
by saosebastiao on Thursday October 09, 2014 @01:31PM
(#8433847)
It has come a long way since I first started using it (0.6 era). Congratulations on the release! I look forward to a future world where I can use it (via Servo) in Firefox, as well as in my Constraint Solver engine, which I hope to reveal for the 2015 Minizinc Challenge.
Re:Rust 0.12.0 released
by nnethercote on Thursday October 09, 2014 @09:44PM
(#8435849)
MiniZinc! There's a blast from the past... I wrote most of the first few versions of the specification and much of the initial implementation. Good to hear it's still being useful.
Re:Rust 0.12.0 released
by blinkingled on Thursday October 09, 2014 @02:40PM
(#8434304)
Does the RFC230 (https://github.com/rust-lang/rfcs/pull/230) removal of green threads give me out of box 1:1 threading or just that std::io uses native threads and the rest has to use green threads only now as an additional outside dependency? Kinda confused given I don't follow Rust all that much.
Really odd that they went with M:N model - if the OS is fast at creating/destroying threads 1:1 is the best model for vast majority of apps.
The default is 1:1 threads. If you use `spawn` in Rust, you get a native thread.
Re:Rust 0.12.0 released
by blinkingled on Thursday October 09, 2014 @02:45PM
(#8434333)
Oh, it is? I must be reading some old docs and mailing list discussions. That's great to hear. Thanks for the clarification!
Re:Rust 0.12.0 released
by steveklabnik on Thursday October 09, 2014 @02:56PM
(#8434397)
It's changed a number of times. First it was M:N, then 1:1 was added, then 1:1 was made the default, now M:N is getting removed.
Does anything preclude M:N threading in a library? It is really useful in quite a number of scenarios.
Re:Rust 0.12.0 released
by steveklabnik on Thursday October 09, 2014 @03:24PM
(#8434523)
The existing libgreen will be moved out to a Cargo library. You just won't be able to seamlessly switch between the two like you did before, you'll have to explicitly use the green threading API instead.
Re:Rust 0.12.0 released
by Blackthorn on Thursday October 09, 2014 @06:27PM
(#8435337)
How will this work if you depend on a lib that uses traditional threading but want to use green threads yourself? That actually comes up a lot at my work.
Re:Rust 0.12.0 released
by steveklabnik on Thursday October 09, 2014 @06:43PM
(#8435399)
You'd have to use one that uses green threads internally.
Basically, in the effort to make the abstraction Just Work between 1:1 and N:M threading, we made green threads so heavyweight that they barely even qualified as green anymore. It's only by removing that abstraction that we could feasibly make them lightweight again.
The current implementation that's being phased out was designed to abstract away the threading model such that libraries could make use of concurrency while the programs that use those libraries could use any threading model they choose, and it would all Just Work. However, in practice this caused too many compromises in the implementation of both the native thread runtime and the green thread runtime, erasing the benefits of both.
Sorry! We're sensitive to your use case, but we just couldn't make it work.
No, and we actually use a "tasklet" library in Servo for the really fine-grained parallelism (per-CSS-block) where any allocation on task spawn would be far too expensive and work stealing is essential.
Could you point me to this? I did a cursory look through the Servo codebase. It just occurred to me that since Servo is pretty much the reason for the existence of Rust, it is probably the best thing to learn Rust by reading code.
I have had a problem learning Rust by example, the codebases I would like to read don't usually work with the latest Rust releases.
I don't really _do_ C++, but if I could talk to Rust from C++ maybe I could start hacking on their codebases.
Edit: I found the http://doc.rust-lang.org/green/index.html is this what you are referring to?
I believe the goal is for there to be an officially-supported green threading library, yes.
Re:Rust 0.12.0 released
by untothebreach on Thursday October 09, 2014 @01:26PM
(#8433805)
excuse my ignorance, but what exactly does 'lifetime elision' mean?
Re:Rust 0.12.0 released
by steveklabnik on Thursday October 09, 2014 @01:30PM
(#8433836)
Part of Rust's ownership system are 'lifetimes.' Without getting into the details, they're an annotation you occasionally add to code in certain situations. Like these two:
fn get_mut<'a>(&'a mut self) -> &'a mut T;
fn print<'a>(s: &'a str);
We used to have a single inference rule for when you didn't need to write the annotation. With RFC 39[1], we added two more. These two extra inference rules removed 87% of the existing annotations, giving you this instead:
fn get_mut(&mut self) -> &mut T;
fn print(s: &str);
1: https://github.com/rust-lang/rfcs/blob/master/active/0039-li...
Re:Rust 0.12.0 released
by untothebreach on Thursday October 09, 2014 @01:32PM
(#8433860)
oh ok, thanks. i knew what lifetimes were, but was confused by the 'elision.' Apparently I didn't connect 'elision' with 'elide.' So, new vocab word for today :)
What kind of cases do you still need to write explicit lifetimes?
Re:Rust 0.12.0 released
by steveklabnik on Thursday October 09, 2014 @05:30PM
(#8435106)
I actually haven't had to since elision was implemented, so I can't give you a good rule of thumb from experience. Here's an overview of how the rules applied to the standard library at the time they were implemented, which is where the percentage came from: https://gist.github.com/aturon/da49a6d00099fdb0e861
Re:Rust 0.12.0 released
by xKingfisher on Thursday October 09, 2014 @11:52PM
(#8436182)
The most common case I have run into is storing a reference inside another data structure.
Basically, after working with lifetimes for so long we realized that a great many functions that take lifetime parameters follow a similar and straightforward pattern. As of this release, we now allow you to omit lifetime parameters entirely for functions that follow this pattern, which is likely the vast majority of functions in your code that previously required such annotations.
The detailed release notes have a more, er, detailed explanation: https://github.com/rust-lang/rust/wiki/Doc-detailed-release-...
This is a great change.
But to clarify, functions which take 2 or more reference inputs won't benefit from this, since the compiler can't determine which lifetime parameter to use, right?
Edit: Never mind, I RTFM. Turns out it can't benefit.
In cases where a function's input and output have the same lifetime, the lifetime is now inferred. So instead of this:
fn f<'a>(x: &'a SomeType) -> &'a OtherType
fn f(x: &SomeType) -> &OtherType
Re:Rust 0.12.0 released
by thomasahle on Thursday October 09, 2014 @03:39PM
(#8434606)
Uhm, what if I didn't want `&OtherType` to have the same lifetime? Would I then write:
fn f<'a>(x: &'a SomeType) -> &'b OtherType
?That would be illegal, because it only makes sense to return a reference when that reference is somehow linked to the lifetime of an input parameter.
(Or when it has a lifetime of `static`, which means the referent is stored in static memory and thus is alive for the whole program.)
What if you're looking up the input in a temporary cache of some kind, and returning a reference to the cached value? The lifetime of the input and output would not be related in that scenario, but the output would not necessarily be 'static (maybe you build a cache, run some functions, tear it all down, then build a new cache with different values and do it all again).
Re:Rust 0.12.0 released
by steveklabnik on Thursday October 09, 2014 @06:04PM
(#8435260)
The lifetime would be matched to the lifetime of the cache, which has to be referred to somehow.
Re:Rust 0.12.0 released
by thomasahle on Thursday October 09, 2014 @04:09PM
(#8434759)
Ah cool, I still have a lot to learn about rust :)
You wouldn't use a reference generally, if you're thinking of creating a new independent object you'd just return that. This is for cases when your return object is a reference into your argument, for example
Yes, though this particular code would not compile because one of the lifetimes is not declared.
Re:Rust 0.12.0 released
by untothebreach on Thursday October 09, 2014 @01:32PM
(#8433853)
ah, got it. thanks!
Is there like a what's new in Firefox but for Rust?
Yes. Click on the link and scroll down.
Noticeably absent is a really good HTTP library.
Chris Morgan is working on teepee[0] though, so it's coming.
There is also hyper which is used by Servo: https://github.com/hyperium/hyper
There's also been tons of progress toward the last features that are blocking the 1.0 release (http://blog.rust-lang.org/2014/09/15/Rust-1.0.html). The long-awaited work on dynamically-sized types is now partially complete, and the only two remaining big hurdles that I can think of are closure reform and trait coherence reform. Onward to stability!