3 ms·

Are they really ready for a 1.0? I'm looking at the standard library, and things (or core functionality of things) like file-system I/O, vectors, strings, _iter

Are they really ready for a 1.0? I'm looking at the standard library, and things (or core functionality of things) like file-system I/O, vectors, strings, _iterators_ … are marked as "experimental"; I was particularly curious as to how they were going to deal with iterators, since I think this is a particularly hard problem. (In many languages these are either pointers (C++) or close to it.¹) I wouldn't really consider a language without a standard library "complete", and a good standard library is important to me in a language. (As it's going to help you get stuff done.) ¹Python, for example, doesn't specify iterator invalidation rules AFAICT; you just have to look at what CPython does. And in CPython, there are ways to make an iterator return a sequence of items that does not make any sense. (e.g., the same item twice, or skipping items…) In C++, invalidation is well-specified, but the compiler doesn't really help catch errors.

steveklabnik 12y ago
1) in general, Rust 1.0 is about language stability. This means that any library not of quality will be pulled out. 2) this means Rust will have a small standard library. But we already have Cargo. So you end up getting lots of packages, they just aren't built-in: they require adding one line to a config file instead. 3) iterator invalidation is a compile-time error in Rust. Rust relies on Iterators quite heavily.
aturon 12y ago
I completely agree that a strong standard library is essential, and we've been working very hard over the last months to set explicit conventions, revamp APIs, and generally get Rust's standard library into a 1.0 state. You shouldn't read much into the "experimental" tags right now; they're part of an API stability tracking system that is heavily in flux at the moment. In particular, for most of the modules you mentioned, only the module name itself has not been marked "stable", while the contents have been. For example, if you look at the Vec type itself: http://static.rust-lang.org/doc/master/std/vec/struct.Vec.html# http://static.rust-lang.org/doc/master/std/vec/struct.Vec.ht... you'll see that most methods are unstable or stable, rather than experimental. (The "experimental" status is currently the default, to help us keep track of API "stabilization" progress.) This stability tracking is part of our general story about API compatibility; you can read more at http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html These markers won't take on their full meaning until we ship 1.0. For 1.0, all of the APIs you mentioned will be "stable", and indeed most of their internals already are. Over the next few weeks, we'll be updating stability markers to reflect the API scrutiny and design work that we've been doing. More generally, for all but a couple of the modules listed at http://static.rust-lang.org/doc/master/std/index.html?search=#modules http://static.rust-lang.org/doc/master/std/index.html?search... we have already performed a detailed scrutiny of the API, and have either landed changes needed for 1.0 or will do so very soon. Most truly experimental APIs have already been deprecated or removed. For IO in particular, you can read a very recent RFC that proposes the final set of API changes for 1.0: https://github.com/rust-lang/rfcs/pull/517 https://github.com/rust-lang/rfcs/pull/517 Hope that helps!

steveklabnik 12y ago

1) in general, Rust 1.0 is about language stability. This means that any library not of quality will be pulled out. 2) this means Rust will have a small standard library. But we already have Cargo. So you end up getting lots of packages, they just aren't built-in: they require adding one line to a config file instead. 3) iterator invalidation is a compile-time error in Rust. Rust relies on Iterators quite heavily.

aturon 12y ago

I completely agree that a strong standard library is essential, and we've been working very hard over the last months to set explicit conventions, revamp APIs, and generally get Rust's standard library into a 1.0 state. You shouldn't read much into the "experimental" tags right now; they're part of an API stability tracking system that is heavily in flux at the moment. In particular, for most of the modules you mentioned, only the module name itself has not been marked "stable", while the contents have been. For example, if you look at the Vec type itself: http://static.rust-lang.org/doc/master/std/vec/struct.Vec.html# http://static.rust-lang.org/doc/master/std/vec/struct.Vec.ht... you'll see that most methods are unstable or stable, rather than experimental. (The "experimental" status is currently the default, to help us keep track of API "stabilization" progress.) This stability tracking is part of our general story about API compatibility; you can read more at http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html These markers won't take on their full meaning until we ship 1.0. For 1.0, all of the APIs you mentioned will be "stable", and indeed most of their internals already are. Over the next few weeks, we'll be updating stability markers to reflect the API scrutiny and design work that we've been doing. More generally, for all but a couple of the modules listed at http://static.rust-lang.org/doc/master/std/index.html?search=#modules http://static.rust-lang.org/doc/master/std/index.html?search... we have already performed a detailed scrutiny of the API, and have either landed changes needed for 1.0 or will do so very soon. Most truly experimental APIs have already been deprecated or removed. For IO in particular, you can read a very recent RFC that proposes the final set of API changes for 1.0: https://github.com/rust-lang/rfcs/pull/517 https://github.com/rust-lang/rfcs/pull/517 Hope that helps!