On 12/30/13 5:00 AM, Armin Ronacher wrote:
But there is so much more work needed. Not just because the language is lacking things that are needed, but because many users of the language are not sure yet how to use it.
Documentation is independent of freezing the language definition.
The compiler and the standard library use widely different patterns and so do libraries written by other people.
IMO, the compiler doesn't need to be updated to modern Rust before 1.0. (`javac` is still not updated to modern Java standards, for example.) The standard library does, however.
There are half a dozen ways to deal with errors now, there are different patterns of how to deal with Options and Results.
These need to be cleaned up before 1.0. Conditions in particular need to be removed.
There are vastly different ways to design whole APIs, how to deal with the traits and so forth.
We'll standardize on something before 1.0. The traits need to be redesigned in general.
There are different patterns to interface with native libraries, different patterns to interface with task local data etc.
Are you referencing RAII versus `with_foo` style methods? The latter are deprecated and should be removed before 1.0.
The introduction of external iterators (which I found the most exciting change of the language) has shown a whole new area of shortcomings in the current feature set (lack decltype when returning composed iterators for instance,
This is the first time I've heard of this as a missing feature, and I'm opposed. This would make typechecking significantly more complex.
non sendable closures etc.).
Is `proc` not sufficient? We could prioritize adding unboxed closures, but since they're backwards compatible as far as I know, I don't see a major need to add them before 1.0.
Not only did it show shortcomings in lacking features, it also put some emphasis on new patterns that are not widely deployed in the stdlib yet.
We need to add them before 1.0, but I personally don't see any major missing language features that we absolutely need to add, except those that are already on the roadmap.
I really hope there is left enough time to actually continue evolving the language and libraries before freezing anything. Especially now that the split into libnative and libgreen is happening it will be important to stay flexible for adjusting the design of the standard library so that we don't end up with two vastly different ways to do IO.
We aren't going to freeze the entire standard library for all time with 1.0. Instead there will be "stability levels" like node.js (something like "frozen", "stabilizing", "unstable", "experimental"). I don't anticipate that all of libstd will be frozen before 1.0. Some modules will, and other modules will not.
As it stands right now, there are too many things that make Rust still frustrating because you program yourself into a corner.
It'd be best to file specific issues here. I'm sympathetic to wanting to adding more features if they're necessary, but none of the *specific* things mentioned in this post seem like blockers to me.
In general I understand the concern, but there are also a huge number of people who just want the language to stabilize so that they can use it in production. The window for relevance is finite and we've been designing the language for a *long* time at this point.
Patrick _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
