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.)
> Managed (GC-ed) pointers are moved to the standard library.
Most uses of the old managed pointer scheme have been excised, but not all just yet (though we have people working on it with great vigor and tireless devotion). They're behind a feature flag though, so it's not possible to use them by accident.
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.
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]
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?
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).
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.
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.
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.
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.)
#[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.
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.
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.
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 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.
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.
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.
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"?
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 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..
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.
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+ ?
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. :)
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.
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.
[+] [-] lifthrasiir|12 years ago|reply
- 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...
[+] [-] kibwen|12 years ago|reply
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.
[+] [-] kibwen|12 years ago|reply
* 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=...
[+] [-] jksmith|12 years ago|reply
Curious about rationale for this. Have details?
[+] [-] spicyj|12 years ago|reply
[+] [-] dmunoz|12 years ago|reply
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?
[+] [-] kibwen|12 years ago|reply
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.
[+] [-] eridius|12 years ago|reply
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
[+] [-] ripter|12 years ago|reply
[+] [-] derekchiang|12 years ago|reply
[0] http://rust-ci.org/projects/
[+] [-] bjz_|12 years ago|reply
[+] [-] keeperofdakeys|12 years ago|reply
[+] [-] sixbrx|12 years ago|reply
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.
[+] [-] ben0x539|12 years ago|reply
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.
[+] [-] kibwen|12 years ago|reply
[+] [-] eridius|12 years ago|reply
#[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.
[+] [-] steveklabnik|12 years ago|reply
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.
[+] [-] swah|12 years ago|reply
[+] [-] swah|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
[+] [-] veeti|12 years ago|reply
[+] [-] pcwalton|12 years ago|reply
[+] [-] malandrew|12 years ago|reply
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
[+] [-] dmunoz|12 years ago|reply
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.
[+] [-] b0b_d0e|12 years ago|reply
[+] [-] eridius|12 years ago|reply
[+] [-] krick|12 years ago|reply
[+] [-] derekchiang|12 years ago|reply
[+] [-] steveklabnik|12 years ago|reply
The language won't change a whole lot, but the libraries will.
[+] [-] renox|12 years ago|reply
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..
[+] [-] panzi|12 years ago|reply
[+] [-] glenjamin|12 years ago|reply
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+ ?
[+] [-] kibwen|12 years ago|reply
[+] [-] cmrx64|12 years ago|reply
[+] [-] Dewie|12 years ago|reply
[+] [-] kibwen|12 years ago|reply
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.
[+] [-] dorolow|12 years ago|reply
[+] [-] coldtea|12 years ago|reply
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.
[+] [-] andrewaylett|12 years ago|reply
[+] [-] aphistic|12 years ago|reply
[+] [-] eterm|12 years ago|reply