Rust 0.10 released(mail.mozilla.org)
mail.mozilla.org
Rust 0.10 released
https://mail.mozilla.org/pipermail/rust-dev/2014-April/009387.html
94 comments
Is it safe to start learning and using Rust for hobby projects or should I wait until 1.0?
Yes, lots of people have started using Rust for hobby projects [0] and their feedback has been invaluable to the development of the language.
[0] http://rust-ci.org/projects/
[0] http://rust-ci.org/projects/
Will there be any impact on Rust due to Brendan Eich quitting Mozilla?
How much involvement did he have on the project?
How much involvement did he have on the project?
Brian Anderson said it better than I could:
Brendan's resignation as CEO will have no effect on Rust or Servo.
Many people at all levels of the organization are huge supporters of Rust, Servo, and Mozilla Research in general.
Brendan's resignation as CEO will have no effect on Rust or Servo.
Many people at all levels of the organization are huge supporters of Rust, Servo, and Mozilla Research in general.
No change: http://www.reddit.com/r/rust/comments/224wgn/eich_steps_down...
(The "mozilla" people (brson and pcwalton) are the people to listen to there.)
(The "mozilla" people (brson and pcwalton) are the people to listen to there.)
AFAIK, there will be no changes due to Eich leaving Mozilla w.r.t Rust. If he had any involvement, it was minor.
None, if any. None that can be discerned from emails.
If you are ok with keeping up to date with the some changes to the language and libraries, then it's great for hobby stuff (that's what I'm using it for). I wouldn't be using it in production just yet, however (not that I thought you were suggesting that).
The core concepts of the language are probably set in stone, but some syntax changes, and fine-trimming of features may occur before 1.0. So I'd say give it a go.
How about giving it a rust instead? wink wink
So how easy would it be to use Rust to compile libraries to be called from non-Rust systems?
I've seen reference to using #[start] and #[no_std] but it wasn't clear with the latter just how much of "std" I'd be giving up? Hopefully that would mean just giving up task spawning and inter-task communication (ok), or would it be everything under the std namespace (not so ok)?
Making this easy would be an easy win to get Rust into active use incrementally. Rust would for example be able to do heavy lifting in computations with Python/Cython providing a web front end dispatcher.
I've seen reference to using #[start] and #[no_std] but it wasn't clear with the latter just how much of "std" I'd be giving up? Hopefully that would mean just giving up task spawning and inter-task communication (ok), or would it be everything under the std namespace (not so ok)?
Making this easy would be an easy win to get Rust into active use incrementally. Rust would for example be able to do heavy lifting in computations with Python/Cython providing a web front end dispatcher.
If you just link some rust code into a C program without #[no_std], once you call anything that makes use of the runtime, it will abort with a lovecraftian error message and a stack trace because it asserts that the runtime exists and has placed some info into thread-local storage. It'll run until then, though!
If you'll only call into rust from a single C-created thread, you could start that thread through a shim that starts up the rust runtime. Rust code can then spawn its own threads in there and all of std might just work.
If you'll only call into rust from a single C-created thread, you could start that thread through a shim that starts up the rust runtime. Rust code can then spawn its own threads in there and all of std might just work.
I don't think #[no_std] has any effect here, other that guaranteeing that know runtime-using functions are called (by not linking in any runtime at all).
I believe you can also just start runtimes in each call into Rust. Obviously it won't be particularly efficient.
I believe you can also just start runtimes in each call into Rust. Obviously it won't be particularly efficient.
That's what I meant re: no_std, yeah.
Would it be possible to lazily start libnative if a call into the runtime is made but there's none there, but then keep it running for that thread for subsequent calls?
Would it be possible to lazily start libnative if a call into the runtime is made but there's none there, but then keep it running for that thread for subsequent calls?
Maybe? The current design is starting a runtime is a blocking call, though, i.e. I think you'd call `native::run`[1] and run anything needing a runtime inside that (I haven't experimented with this part of our FFI in detail).
[1]: http://static.rust-lang.org/doc/master/native/fn.run.html
[1]: http://static.rust-lang.org/doc/master/native/fn.run.html
The third production deployment of Rust is as a Ruby extension.
I'm on my phone, but if you look up the 'SprocketNES' edition of the Bay Area Rust Users Group, you can see wycats talk about the details.
I'm on my phone, but if you look up the 'SprocketNES' edition of the Bay Area Rust Users Group, you can see wycats talk about the details.
#[start] only applies to executables, not libraries.
#[no_std] means that no part of libstd would be provided. This is typically expected to be used by, say, kernel developers. libstd itself is statically linked (by default) into your built product, so if you want you can compile your Rust library and use it on a system that has never had Rust installed.
#[no_std] means that no part of libstd would be provided. This is typically expected to be used by, say, kernel developers. libstd itself is statically linked (by default) into your built product, so if you want you can compile your Rust library and use it on a system that has never had Rust installed.
It's not very difficult at all to call Rust libraries from other languages by using #[no_std] and exposing a C API. You're correct in that this does currently dispose of the entire standard library, which is rather unfortunate. We're still exploring options for partitioning the stdlib into levels such that you can lose just the stuff that needs a runtime (heap allocation, concurrency) without losing all the other goodies (overloaded operators, iterators, etc.)
Rust can be called from other languages even with std. The main thing you'll be missing is the ability to handle task failure (which will just cause a process abort), but also protection from stack overflow. For full integration it will require a small amount of runtime API that is yet to be determined.
I'd really love to see an update to your "Calling Rust from Ruby" post detailing these new features.
I love that the Install button gave me an .exe directly - has it always been like that? I don't remember it being this easy the first time I looked at Rust. Kudos.
Oh well it isn't that easy:
C:\Users\swah>rustc first.rust
error: could not exec the linker `gcc`: file not found
error: aborting due to previous errorIt was not, that's actually only about a week old.
Maybe somewhat rude question, but how close to being "ready" Rust is? I mean, should I start using it already if not only for the sake of language itself? How stable is it now? How much it will probably change 'till 1.0? How soon it can be expected to be "production ready"?
There are three production deployments of Rust that we know about.
The language won't change a whole lot, but the libraries will.
The language won't change a whole lot, but the libraries will.
> how close to being "ready" Rust is?
I think that this depends on your expectations, I was quite disappointed to find that there isn't a clean way to make 'unit types' (second, millisecond, meters, etc) in Rust..
I wouldn't use Rust for anything but toy project..
I think that this depends on your expectations, I was quite disappointed to find that there isn't a clean way to make 'unit types' (second, millisecond, meters, etc) in Rust..
I wouldn't use Rust for anything but toy project..
> there isn't a clean way to make 'unit types' (second, millisecond, meters, etc) in Rust..
Actually, there's this bit on Tuple Structs[1] in the tutorial:
> Types like this can be useful to differentiate between data that have the same underlying type but must be used in different ways.
Actually, there's this bit on Tuple Structs[1] in the tutorial:
> Types like this can be useful to differentiate between data that have the same underlying type but must be used in different ways.
struct Inches(int);
struct Centimeters(int);
1.0 is planned for this year. To the rest I don't know the answer. But you should use Rust so you might find problems and report them, because after 1.0 they can't do breaking changes.
The language will still change a lot before 1.0, so I don't recommend serious usage in production, unless you are prepared for updating your codebase every now and then. However, many people have already started using Rust for personal projects, and their feedback has been invaluable to the development of the language!
I've seen it stated a few times that after Rust 1.0 there will be no more backwards compatible changes.
Does that mean ever, or just that it'll be stable for some time before people start considering a 2.0 to try and fix whatever warts are discovered from wider usage of 1.0+ ?
Does that mean ever, or just that it'll be stable for some time before people start considering a 2.0 to try and fix whatever warts are discovered from wider usage of 1.0+ ?
It certainly doesn't necessarily mean ever. Who even knows who will be leading the project ten years from now! But it does mean that it will be quite a while before the hypothetical 2.0 where we could consider breaking backwards compatibility. How long "quite a while" will turn out to be, I can't say. But it will certainly be an improvement over the current situation, where the language breaks about once a week. :)
We will follow http://semver.org/
Highlights (no particular order, partially reflects my personal interests):
- Managed (GC-ed) pointers are moved to the standard library. There is no special syntax (formerly `@`) nor special header (for vectors containing managed pointers) required.
- Special treatments on `str` and `[T]` vectors are being generalized ("Dynamically Sized Types").
- Lifetimes of temporary expressions have changed in somewhat more intuitive way.
- Syntax extensions are now exportable, documentable and much more flexible ("procedural macro").
- Language simplifications: `do` syntactic sugar is removed, `priv` is now default, no trait bounds by default (e.g. formerly `:Send` was implied for `~Trait`).
- The smart pointer usage has been improved with new `Deref` and `DerefMut` traits.
- There are now many auxiliary standard libraries instead of a single `extra` library.
- Usual library fixes, redesigns and influx took place. Most prominent change is an introduction of growable vector type, `Vec<T>`, which subsumes the original `~[T]` type.
- Rustpkg is gone, long live Cargo! Rustc has also combined many related options into umbrella flags (e.g. `-C`).
As prior point releases of Rust did, Rust 0.10 does not represent a significant milestone. It is always recommended to use the most recent development version (master) of Rust, but it had been a great undertaking to compile Rust from scratch. From 0.10 onwards, however, there are official nightly versions [1] and brave souls can play with master more conveniently now. (They are currently not signed yet, so take that in mind.)
[1] https://mail.mozilla.org/pipermail/rust-dev/2014-March/00922...
- Managed (GC-ed) pointers are moved to the standard library. There is no special syntax (formerly `@`) nor special header (for vectors containing managed pointers) required.
- Special treatments on `str` and `[T]` vectors are being generalized ("Dynamically Sized Types").
- Lifetimes of temporary expressions have changed in somewhat more intuitive way.
- Syntax extensions are now exportable, documentable and much more flexible ("procedural macro").
- Language simplifications: `do` syntactic sugar is removed, `priv` is now default, no trait bounds by default (e.g. formerly `:Send` was implied for `~Trait`).
- The smart pointer usage has been improved with new `Deref` and `DerefMut` traits.
- There are now many auxiliary standard libraries instead of a single `extra` library.
- Usual library fixes, redesigns and influx took place. Most prominent change is an introduction of growable vector type, `Vec<T>`, which subsumes the original `~[T]` type.
- Rustpkg is gone, long live Cargo! Rustc has also combined many related options into umbrella flags (e.g. `-C`).
As prior point releases of Rust did, Rust 0.10 does not represent a significant milestone. It is always recommended to use the most recent development version (master) of Rust, but it had been a great undertaking to compile Rust from scratch. From 0.10 onwards, however, there are official nightly versions [1] and brave souls can play with master more conveniently now. (They are currently not signed yet, so take that in mind.)
[1] https://mail.mozilla.org/pipermail/rust-dev/2014-March/00922...
> Managed (GC-ed) pointers are moved to the standard library.
For example, note that the replacement type in question, std::gc::Gc, is still internally backed by the old managed pointers, although this will not be the case once we finally implement a proper garbage collector. And even then if you really need multiple owners of a single value we'd really prefer that you use our reference-counted pointer (std::rc::Rc) instead, along with weak pointers (std::rc::Weak) if your data has cycles. Reference counting in Rust is generally surprisingly cheap, since the refcount only gets bumped if you explicitly clone the pointer; otherwise the pointer simply gets passed around as an owned value.
Wait, I don't understand these version numbers. Wasn't the previous release 0.9? I was expecting the new release to be 1.0, or 0.91, or something like that. Maybe this is standard practice for all I know.
Rust uses semantic versioning (http://semver.org/). The number after the dot is simply a minor version revision, and can increment without bound.
A 1.0 release of Rust is targeted for later this year. There will be at least one more minor version (0.11), and possibly more, before that point.
A 1.0 release of Rust is targeted for later this year. There will be at least one more minor version (0.11), and possibly more, before that point.
Unfortunately Rust is not actually using semver, which I always found confusing because they seem to be in support of it, and they even include a semver library in the core distribution. If they were following semver, this release would be version 0.10.0 (notice the patch version).
The point of semver is to stick to a standard, instead of every project deviating from common practice in subtly incompatible ways.
The point of semver is to stick to a standard, instead of every project deviating from common practice in subtly incompatible ways.
Right, we didn't really "adopt" semantic versioning until sometime after 0.1, and so we've never really gotten into the habit of including the patch revision (and with one exception, we've never issued a patch for any of our unstable releases anyway).
Here's the issue for getting us to adhere to semver proper: https://github.com/mozilla/rust/issues/11396
Here's the issue for getting us to adhere to semver proper: https://github.com/mozilla/rust/issues/11396
There's an open issue for this: https://github.com/mozilla/rust/issues/13289
> If they were following semver, this release would be version 0.10.0 (notice the patch version).
Actually, since they are doing backwards incompatible changes in every release, this version would be more like 10.0.0.
They are deviating from semver for now, I hope they get on it properly for 1.0.0 and beyond.
Actually, since they are doing backwards incompatible changes in every release, this version would be more like 10.0.0.
They are deviating from semver for now, I hope they get on it properly for 1.0.0 and beyond.
I, for one, hope there are many more minor releases before any 1.0 - as many as it takes, and then some. Given the rate of breaking changes and how awesome they turn out to be, I would really hate to see this extremely promising language get stuck with warts for the sake of expedience. By the time 2.0 is on the horizon, everyone will have gotten used to and even depend on them.
Unfortunately there /seem/ to be a lot of people holding back from using it until the language is stable.
If so, that virtually guarantees some regret after it becomes stable and new users flood in with new use cases that need breaking changes to address in an optimal manner.
Edit: Perhaps I was too subtle. If you think rust is something that may meet your needs in the future, you should do future-you a favor and start using it now when there is still time to remove warts in a backwards incompatible way.
If so, that virtually guarantees some regret after it becomes stable and new users flood in with new use cases that need breaking changes to address in an optimal manner.
Edit: Perhaps I was too subtle. If you think rust is something that may meet your needs in the future, you should do future-you a favor and start using it now when there is still time to remove warts in a backwards incompatible way.
That theme is exactly what makes me worry that the team will give in to pressure to make a 1.0 before it's really ready.
I can understand the desire for stability before wrapping your head around a new language (typestate..), but if you're interested in Rust then you either patiently watch from afar, or at some point you just jump in and live with the breaking changes.
Semver seems like a straightjacket at the discontinuity of 0.x->1.0 if you don't want to commit to significant velocity of major versions. Perhaps the thing to do is define a second pre-1.0 series at 0.99.x, where breaking changes are made deliberately and include a source rewriting tool where possible?
I can understand the desire for stability before wrapping your head around a new language (typestate..), but if you're interested in Rust then you either patiently watch from afar, or at some point you just jump in and live with the breaking changes.
Semver seems like a straightjacket at the discontinuity of 0.x->1.0 if you don't want to commit to significant velocity of major versions. Perhaps the thing to do is define a second pre-1.0 series at 0.99.x, where breaking changes are made deliberately and include a source rewriting tool where possible?
We are going to commit to backwards compatibility at 1.0, but many (not all) libraries will be unstable, and we can always add stuff to the language as long as it doesn't compromise backwards compatibility for existing code. All 1.0 means is "we're going to stop breaking your code, and we have a reasonable, stable platform on which a lot of useful software can be written".
What does "really ready" mean when it comes to Rust?
That's the kind of vague goal that people will keep using as an excuse for not focusing on stability, and providing a product that's actually usable.
When it comes to programming languages, it's dangerous for their implementors to not produce something that's seriously usable as soon as possible, even if it means accepting some imperfections in the early stable versions.
With each passing day, Rust becomes closer to being something like Perl 6: anticipated, probably useful, but never actually "ready" enough to be usable. While I'm more optimistic about Rust potentially having a far brighter future than Perl 6, the lack of stability does cause unease.
That's the kind of vague goal that people will keep using as an excuse for not focusing on stability, and providing a product that's actually usable.
When it comes to programming languages, it's dangerous for their implementors to not produce something that's seriously usable as soon as possible, even if it means accepting some imperfections in the early stable versions.
With each passing day, Rust becomes closer to being something like Perl 6: anticipated, probably useful, but never actually "ready" enough to be usable. While I'm more optimistic about Rust potentially having a far brighter future than Perl 6, the lack of stability does cause unease.
Rust is usable today.
Yes, sometimes the language/lib changes and you have to go through and edit all of your existing code. You can stick with point releases to minimize this, but most likely you won't want to, because these breaking changes fix problems and annoyances!
If you take a look at these changes for 0.10, they make progress on the language itself, and leaving these things as-is to stabilize the language would have been a terrible mistake. There are more of these in the line (DST..), as there should be. IMHO, Rust will be "ready" when such changes stop creating real progress.
Having watched Rust for several years now, it has always been apparent that it isn't an overnight language. Despite the goal of being based on only existing research, getting new implementations of ideas right takes careful deliberation. A large part of language design is getting the core features to play well with one another in ways that make sense, and creating well-thought-out core libraries that properly implement standard abstractions. Every inconsistency and incompleteness at this stage will lead to constant (poor) reinvention of these concepts to achieve the missing capabilities, and a subsequent proliferation of ecosystem glue code to make the different implementations communicate. A large part of why dynamic languages can be so expressive is that their core abstractions contain enough indirection to add missing functionality in a backwards-compatible manner, but a close-to-the-metal language simply does not have that luxury.
Yes, sometimes the language/lib changes and you have to go through and edit all of your existing code. You can stick with point releases to minimize this, but most likely you won't want to, because these breaking changes fix problems and annoyances!
If you take a look at these changes for 0.10, they make progress on the language itself, and leaving these things as-is to stabilize the language would have been a terrible mistake. There are more of these in the line (DST..), as there should be. IMHO, Rust will be "ready" when such changes stop creating real progress.
Having watched Rust for several years now, it has always been apparent that it isn't an overnight language. Despite the goal of being based on only existing research, getting new implementations of ideas right takes careful deliberation. A large part of language design is getting the core features to play well with one another in ways that make sense, and creating well-thought-out core libraries that properly implement standard abstractions. Every inconsistency and incompleteness at this stage will lead to constant (poor) reinvention of these concepts to achieve the missing capabilities, and a subsequent proliferation of ecosystem glue code to make the different implementations communicate. A large part of why dynamic languages can be so expressive is that their core abstractions contain enough indirection to add missing functionality in a backwards-compatible manner, but a close-to-the-metal language simply does not have that luxury.
> what does "really ready" mean
https://github.com/mozilla/rust/issues?direction=asc&labels=...
https://github.com/mozilla/rust/issues?direction=asc&labels=...
How does a non-static list of issues to resolve really help? The latest was added merely 4 days ago.
If anything, that's yet another way to justify not getting a stable release out there. It's the old "We can't release yet, still have bugs to fix!" trap that catches many software development teams.
There will always be some issues, so insisting on a vague notion of "perfection" becomes far more harmful than just getting at least something out there than users can actually use.
If anything, that's yet another way to justify not getting a stable release out there. It's the old "We can't release yet, still have bugs to fix!" trap that catches many software development teams.
There will always be some issues, so insisting on a vague notion of "perfection" becomes far more harmful than just getting at least something out there than users can actually use.
There will always be bugs: there are currently 1504 open issues on the repository. Those 48 represent the backwards incompatible changes that still need to be made. And 1.0 has 108 open issues in total.
I've been learning a teeny tiny bit about C, for the low-level aspects. Rust seems much better (at least eventually), but I was afraid that it was so good that it spoil me and turn me off going back to studying C. But maybe this really is the best time to get into Rust - for Rust to get as an active community as possible. Even though increasing that community participation might only manifest itself as more newbie questions on IRC on my part. :)
Have no fear asking newbie questions on the IRC, we were all there once :). #rust also has a reputation for being quite friendly and welcoming to new folks.
This is standard practice. The decimal points are generally dividers between major, minor, and patch numbers. Hence why it is not uncommon to see something with a version number like 2.1.4 or similar.
It's not a decimal number.
It's just two numbers separated by a dot (major version number DOT minor version number).
Perhaps if we switched to using something like 0-10 or 0:10, people wouldn't expect any reference to . to mean a decimal number.
It's just two numbers separated by a dot (major version number DOT minor version number).
Perhaps if we switched to using something like 0-10 or 0:10, people wouldn't expect any reference to . to mean a decimal number.
It's not a decimal number, it's two numbers separated by a period. So just as '10' follows '9', '1.10' follows '1.9'.
10 comes after 9. The previous release was 0.9, not 0.90.
If you pronounce it "Naught point Ten" you should understand how it comes after "Naught point Nine".
What resources would you recommend for learning Rust? There's the official tutorial but I have to admit that the later parts of it go over my head a little bit.
Rust for Rubyists is a great resource I can vouch for (not just for Rubyists): http://www.rustforrubyists.com/
I was disappointed in how little detail this went into on the different pointer types and how/when to use each one. IIRC, it doesn't even mention lifetimes, which are the feature that's currently stopping me from writing any rust code (because I don't know how to fix lifetime problems).
As far as fixing lifetime errors is concerned, I would recommend breaking your code down into a simpler form so that you can look at the lifetimes from a broader perspective. If you have a simple test case that mimics the same error that your main program has and you still can't solve it, you can simply make a gist for it and ask on the IRC and they usually are able to point out the error. In my experience with lifetime errors, doing it in this method sometimes reveals the simple error I was over looking, or in other cases after asking on IRC I learn something new about lifetimes.
I wrote this too: http://words.steveklabnik.com/pointers-in-rust-a-guide
I can vouch for this—the overlap between the two languages is mostly the anonymous function syntax.
To be sure I think the most similar language to rust would be probably c++. At least I get a distinct "created by c++ developers" whenever I use it.
Not that that is a bad thing, just that if you've programmed in almost any imperative language you're fine reading that online book. I'd love to use rust to replace my C stuff in the future if possible once it stabilizes. But until then I am just popping back to that book every other even .N release to have a look-see at progress.
Not that that is a bad thing, just that if you've programmed in almost any imperative language you're fine reading that online book. I'd love to use rust to replace my C stuff in the future if possible once it stabilizes. But until then I am just popping back to that book every other even .N release to have a look-see at progress.
Despite its unfortunate name that unnecessarily limits the audience which might find it useful, you might want to check out http://www.rustforrubyists.com/
It's basically a tutorial for people coming from typeless, pointer-less dynamic languages, whereas the official Rust tutorial assumes familiarity with the concepts that a C (or C++, C#, Objective-C) developer would know
It's basically a tutorial for people coming from typeless, pointer-less dynamic languages, whereas the official Rust tutorial assumes familiarity with the concepts that a C (or C++, C#, Objective-C) developer would know
My love of alliteration has certainly harmed my audiences. Oh well. :/
I am not a rubyist and I almost dismissed your book because of the title because I assumed it would lean heavily on concepts from ruby with which I would not be familiar and therefore be no more enlightening than the official rust tutorial. i.e. I assumed it would teach one foreign concept based on another foreign concept.
Originally I envisioned more of that, it just didn't shape up that way.
Hopefully I will have something better and more generic near the 1.0 release ;)
Hopefully I will have something better and more generic near the 1.0 release ;)
Awesome. Looking forward to it.
[deleted]
[deleted]
It's hard to say, as it depends on what your previous experience is with similar languages to Rust.
Plenty of people are suggesting Rust for Rubyists, which is a good resource. I personally found it too simple, which is not a reflection on the resource but instead what I was looking for. It is likely to be exactly what plenty of people are looking for.
I wanted to give some motivation for keeping on at the official tutorial. Some of its contents went over my head initially as well, but I read it again a couple of weeks later, and everything clicked into place. It's a really awesome guide to the language, and the links at the end to guides to various more specialized parts of the language are similarly awesome.
Plenty of people are suggesting Rust for Rubyists, which is a good resource. I personally found it too simple, which is not a reflection on the resource but instead what I was looking for. It is likely to be exactly what plenty of people are looking for.
I wanted to give some motivation for keeping on at the official tutorial. Some of its contents went over my head initially as well, but I read it again a couple of weeks later, and everything clicked into place. It's a really awesome guide to the language, and the links at the end to guides to various more specialized parts of the language are similarly awesome.
One thing that has really helped me is picking a project that I really wanted to make and learning Rust while making the project. A read through of the tutorial also went over my head at first, but when the concepts started to show up in my program the tutorial also started to make sense. There is the documentation which you can also look through for specific examples, and also there are lots of small resources to read here http://static.rust-lang.org/doc/master/index.html Probably the best resource though is the IRC where you can ask just about any question and they'll usually answer it in a very short time.
And if they don't, ask a few hours later.
I have never actually read it myself, and I don't know what version of Rust it currently targets, but I've heard good things about Rust For Rubyists (http://www.rustforrubyists.com), written by Steve Klabnik.
0.9, I guess.
At some point (shortly after the 0.9 release?) one of the first examples stopped working with a then-current git build, so I stopped reading it and concentrated on the official tutorial more.
At some point (shortly after the 0.9 release?) one of the first examples stopped working with a then-current git build, so I stopped reading it and concentrated on the official tutorial more.
I actually updated it to 0.10, I just haven't deployed it yet. It'll be up in a few hours.
Congrats to all developers on the release! Here's a selection of some of my personal favorite changes in this release cycle:
* Automatically-generated nightly binaries for all first-tier platforms [1]
* Switching the default hashmap over to Robin Hood hashing [2]
* Turning on native threading by default, in lieu of the green thread runtime [3]
* The removal of conditions in favor of a standardized type for returning I/O results, which will (by default) generate a warning if the result is ignored [4]
* The extension of the lifetimes of temporary values, which should greatly reduce the occasions where you have to assign a name to a temporary result in an effort to please the compiler [5] [6]
And if you're thrown by the idea that version 0.10 follows version 0.9, know that I voted for 0.A (alas). 1.0 is still expected for later this year, though no promises!
Remember, Rust 1.0 is not the milestone when the language is finished, but rather the milestone when backwards-incompatible changes to the language will no longer be made. See the "backcompat-lang" tag on the issue tracker for a list of outstanding blockers. [7]
[1] https://mail.mozilla.org/pipermail/rust-dev/2014-March/00922...
[2] https://github.com/mozilla/rust/pull/12081
[3] https://github.com/mozilla/rust/pull/12833
[4] https://mail.mozilla.org/pipermail/rust-dev/2014-February/00...
[5] http://smallcultfollowing.com/babysteps/blog/2014/01/09/rval...
[6] https://github.com/mozilla/rust/pull/11585
[7] https://github.com/mozilla/rust/issues?direction=asc&labels=...
* Automatically-generated nightly binaries for all first-tier platforms [1]
* Switching the default hashmap over to Robin Hood hashing [2]
* Turning on native threading by default, in lieu of the green thread runtime [3]
* The removal of conditions in favor of a standardized type for returning I/O results, which will (by default) generate a warning if the result is ignored [4]
* The extension of the lifetimes of temporary values, which should greatly reduce the occasions where you have to assign a name to a temporary result in an effort to please the compiler [5] [6]
And if you're thrown by the idea that version 0.10 follows version 0.9, know that I voted for 0.A (alas). 1.0 is still expected for later this year, though no promises!
Remember, Rust 1.0 is not the milestone when the language is finished, but rather the milestone when backwards-incompatible changes to the language will no longer be made. See the "backcompat-lang" tag on the issue tracker for a list of outstanding blockers. [7]
[1] https://mail.mozilla.org/pipermail/rust-dev/2014-March/00922...
[2] https://github.com/mozilla/rust/pull/12081
[3] https://github.com/mozilla/rust/pull/12833
[4] https://mail.mozilla.org/pipermail/rust-dev/2014-February/00...
[5] http://smallcultfollowing.com/babysteps/blog/2014/01/09/rval...
[6] https://github.com/mozilla/rust/pull/11585
[7] https://github.com/mozilla/rust/issues?direction=asc&labels=...
>* Turning on native threading by default, in lieu of the green thread runtime [3]
Curious about rationale for this. Have details?
Curious about rationale for this. Have details?
The switch was inspired by this mailing list thread back in November: http://thread.gmane.org/gmane.comp.lang.rust.devel/6479
A select quote:
> Memory mapped I/O is also an incredibly important feature for I/O performance, and there's almost no reason to use traditional I/O on 64-bit. However, it's a no-go with M:N scheduling because the page faults block the thread.
This is more or less why Java switched to native threads a decade and a half ago. Although in that case, it was page faults from hitting swap rather than memory-mapped IO. And in both cases, compatibility with existing native code which makes blocking system calls was also a consideration. It's reassuring that Rust is following a path well-worn by other serious languages.
Now it's just a question of waiting for Go and Node to do the same.
> Memory mapped I/O is also an incredibly important feature for I/O performance, and there's almost no reason to use traditional I/O on 64-bit. However, it's a no-go with M:N scheduling because the page faults block the thread.
This is more or less why Java switched to native threads a decade and a half ago. Although in that case, it was page faults from hitting swap rather than memory-mapped IO. And in both cases, compatibility with existing native code which makes blocking system calls was also a consideration. It's reassuring that Rust is following a path well-worn by other serious languages.
Now it's just a question of waiting for Go and Node to do the same.
Note, be very careful with "mmap is the fastest way to do IO". That's not true 90% of the time.
mmap is the fastest way to do IO when the OS already has file contents in memory and it's more than a few pages so setup of mmap() call is cheaper than memcopying data from kernel space.
However mmap is terrible for cold IO. The problem is that mmap is IO-by-sideeffect-of-pagefaults. One has to use madvise() very carefully to make sure that the OS reads useful parts of a file during a pagefault. mmap style of IO is also susceptible to access-pattern bugs, eg even the Linux toolchain gets it deadly wrong and ends up doing IO backwards: https://blog.mozilla.org/tglek/2010/05/27/startup-backward-c....
mmap is even worse on Windows. Windows has no madvise(), OSX equivalent is pathetic. OSX and Windows read mmaped files in bizzarely small chunks, etc.
mmap has the worst error-handling semantics of all IO methods. Linux gives you a super-hard-to-wrap SIGBUS, Windows forces use of slightly-less-horrific SEH http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
mmap is even worse on Windows. Windows has no madvise(), OSX equivalent is pathetic. OSX and Windows read mmaped files in bizzarely small chunks, etc.
mmap has the worst error-handling semantics of all IO methods. Linux gives you a super-hard-to-wrap SIGBUS, Windows forces use of slightly-less-horrific SEH http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
And this is not an issue with Erlang?
Google has been pushing for performance improvements in native threads for a similar reason. If that's successful, I think the plan is for Go to switch too, but I can't find any links about it atm.
https://www.youtube.com/watch?v=KXuZi9aeGTw
That might be the talk you are thinking about. I am keeping an eye on this. If we can have our cake and eat too w.r.t green threads and performance I will be very happy.
That might be the talk you are thinking about. I am keeping an eye on this. If we can have our cake and eat too w.r.t green threads and performance I will be very happy.
Your [5] is broken. Looks like it should be http://smallcultfollowing.com/babysteps/blog/2014/01/09/rval....
I must have misunderstood what was changing in rust re: pointer types. My understanding was that managed boxes using the sigil @ were being removed, and GC moved to the standard library std::rc::Rc.
When I last read the tutorial, I read master instead of 0.9, and thought that the existence of the managed box in the tutorial was only due to it not yet being updated. But the 0.10 tutorial retains references to managed boxes using thee sigil @.
Is the tutorial not yet updated? Did @ not get removed from the core in time for 0.10? Or did I just misunderstand what is actually happening?
When I last read the tutorial, I read master instead of 0.9, and thought that the existence of the managed box in the tutorial was only due to it not yet being updated. But the 0.10 tutorial retains references to managed boxes using thee sigil @.
Is the tutorial not yet updated? Did @ not get removed from the core in time for 0.10? Or did I just misunderstand what is actually happening?
Agh, you're right! Issue filed: https://github.com/mozilla/rust/issues/13287
You're correct in that @ has not yet entirely been removed from the core language, because some old vestiges of its use in the compiler itself (specifically the AST) have yet to be removed. In order to actually use them nowadays, though, you have to opt-in with an attribute in your source file, so it's not possible to use them without being explicit about it. And we're certainly not encouraging anyone to actually use them, which is why it's quite embarrassing that mentions of them managed (heh) to slip through in the tutorial.
You're correct in that @ has not yet entirely been removed from the core language, because some old vestiges of its use in the compiler itself (specifically the AST) have yet to be removed. In order to actually use them nowadays, though, you have to opt-in with an attribute in your source file, so it's not possible to use them without being explicit about it. And we're certainly not encouraging anyone to actually use them, which is why it's quite embarrassing that mentions of them managed (heh) to slip through in the tutorial.
Most likely the tutorial didn't get updated. It doesn't get a lot of love.
kibwen already posted[1] more details about @ in Rust 0.10, but the short of it is, @ still exists but is gated behind a feature flag. Code that uses it is still being updated. The functionally equivalent replacement is std::gc::Gc, but you should consider std::rc::Rc for reference counting instead (which supports weak references).
[1] https://news.ycombinator.com/item?id=7525598
kibwen already posted[1] more details about @ in Rust 0.10, but the short of it is, @ still exists but is gated behind a feature flag. Code that uses it is still being updated. The functionally equivalent replacement is std::gc::Gc, but you should consider std::rc::Rc for reference counting instead (which supports weak references).
[1] https://news.ycombinator.com/item?id=7525598
> Most likely the tutorial didn't get updated. It doesn't get a lot of love.
Ah, that's a shame. I actually just mentioned the tutorial as an awesome resource in another comment.
Maybe my understanding of the Rust language isn't as good as I thought it was, as most of it comes from reading the tutorial and the related guides linked at the end.
I'm a big fan of high quality documentation, and I assumed since the current tutorial was so well written, it was being handled actively already. This is actually one area I would love to step up and help Rust with. I've previously gone so far as to read some of the compiler implementation, but my experience with programming languages is still stuck in the interpreters stage, so it didn't get very far.
Ah, that's a shame. I actually just mentioned the tutorial as an awesome resource in another comment.
Maybe my understanding of the Rust language isn't as good as I thought it was, as most of it comes from reading the tutorial and the related guides linked at the end.
I'm a big fan of high quality documentation, and I assumed since the current tutorial was so well written, it was being handled actively already. This is actually one area I would love to step up and help Rust with. I've previously gone so far as to read some of the compiler implementation, but my experience with programming languages is still stuck in the interpreters stage, so it didn't get very far.
The guides are up-to-date and maintained, but the tutorial itself is long, bulky, and ill-maintained. There is a contractor working on rewriting it.
> I've previously gone so far as to read some of the compiler implementation
The guys on #rust-internals are super nice and can help you a great deal if you are interested. But tbh, we really need more contributions with respect to documentation. Again #rust-internals can guide you if you are interested in lending a hand.
The guys on #rust-internals are super nice and can help you a great deal if you are interested. But tbh, we really need more contributions with respect to documentation. Again #rust-internals can guide you if you are interested in lending a hand.