There's no way they could gather enough experience with the new API within three weeks in order to commit to it for the next decades of Rust.
There has been a lot of churn recently it's true - more than ever - but much of this activity is directly motivated by making these kinds of commitments. The changes you are seeing now are the culmination of years of iteration and we really do think we're on the home stretch. If we can live with these APIs for a release cycle or two we'll have a good deal of confidence.
Frankly it would be better not to cut it this close, but Rust 1.0 is going to be a great foundation that we can commit to. There will be mistakes and misdesigns that we will have to live with but that is true for all languages.
I too think that the culture and community of the Rust project is special and am always heartened to hear others agree. Whatever happens with Rust 1.0 it's going to be something for a lot of people to be proud of.
The final API will actually be quite similar to the existing std::io in most respects. It fixes a few longstanding complaints, reorganizes the modules into a flatter hierarchy, and renames to match conventions elsewhere. These are tweaks and polish, not a complete rethink.
Where there are deeper changes (e.g. introducing OsString), we are codifying trends that are already in place (e.g. the env_as_bytes function).
In general, the changes to IO also all make the design more conservative, following traditional APIs more closely, exposing fewer high-level abstractions, and removing questionable APIs.
For most applications, updating will just be a matter of updating names and imports.
It's a module, not core syntax/semantics, so they don't have to commit to anything about it for the "next decades of Rust".
Besides it's not like they're gonna do a "complete redesign" in 3 weeks from scrach and knowing nothing about how it's gonna come out.
They're gonna redesign it based on what they've known for years to be its pain points, and with all the experience they've had using the previous api.
Furthermore, consider that many programming languages have gotten popular post-1.0, so if anything, they had _even less_ experience than we will have.
After using Rust a little, I get the feeling that the borrow system, the big innovation, is in good shape. The type system is clunky. Take a look at this date/time module:
https://github.com/lifthrasiir/rust-chrono/blob/master/src/d...
Note that none of this code does any computation. It's all field access and update. It's not a multi-calendar system with time zone tables. This is the code for stuffing the year into a Datetime object:
#[inline]
fn with_year(&self, year: i32) -> Option<DateTime<Off>> {
self.local().with_year(year).and_then(|datetime|
self.offset.from_local_datetime(&datetime).single())
}
There are some neat ideas in the type system. One is that if you have something which might not be able to return a value, you have it return an "Option<T>" value, which can have a value of type T, or a value of None. Sorting out what was returned requires a "match" statement, which is rather verbose. It's an elegant way to avoid null pointers and error codes, but it's quite verbose in practice. The business with "and_then" and the closure above is to deal with that problem. See "Option Monads in Rust" ("http://www.hoverbear.org/2014/08/12/option-monads-in-rust/") for an explanation.
In Python, situations like this raise a ValueError exception. In Go, situations like this return (uselessvalue, err). The Rust solution is formally correct, but complex and verbose for what it's doing.
I'm worried that all this verbiage will turn new users off. It turns me off, and I have a background in formal systems.
> Sorting out what was returned requires a "match" statement, which is rather verbose
is particularly low quality: even the code you quote above demonstrates (or at least hints) that this isn't true. `Option` provides a variety of combinator methods that avoid the need for manual pattern matching: http://doc.rust-lang.org/nightly/std/option/enum.Option.html
Also, this isn't extremely true either:
> Note that none of this code does any computation. It's all field access and update
Doesn't accessing fields and updating them count as computation? Anyway, nothing in date/time handling is just field access and updating; time libraries are hard (and I'm very happy that lifthrasiir is tackling it, their libraries are always high-quality and diligently written). There's actual "real" computation happening, you can see this looking at the underlying implementation: https://github.com/lifthrasiir/rust-chrono/blob/cf5e2f322fbc... (and tracking those functions calls through inside that module).
I've never once regretted the fact that Rust has no null pointers, which is basically what you're criticizing. Null pointers cause so many bugs that the minor effort saved by having them is in no way worth it.
1. Null references are undesirable. Good decision. 2. Exceptions are undesirable. Arguable, but not bad. 3. There should be some way to optionally return a null result from a function. Reasonable enough. 4. Functional composition is good, allowing one to write h(g(f(a))) Standard in most languages. 5. Object method syntax is good, allowing one to write a.f().g().h() to compose functions. Standard in most languages. 6. Types are determined at compile time. Required for speed. 7. Function overloading based on parameter types is bad.
There are unintended consequences of these decisions. The Option<T> wrapper type can have a value of None, which is not a type to which methods can be applied. So, for functions that return Option, the common "a.f().g().h()" form won't work. Workarounds are available, but they're either wordy ("'if let' and a couple of extra lines") or obscure (using a closure as shown in the example).
It may be better in such cases to avoid an object-oriented style, and do composition as "h(g(f(a)))". If all the functions take Option inputs and return Option outputs, None can be passed through the chain of functions by having each function return None if the input is None. Because Rust doesn't support function overloading for plain functions, the names have to be unique within the namespace, so you can't have both "f(a: f64) => Option<f64>" and "f(a: Option<f64>) => Option<f64>". Although some hack with macros/metaprogramming might allow that, by creating wrappers to pass through None.
This is getting to be a lot of machinery to do something that comes up frequently.
This is not true. I'd like you to the playpen, but it would get autokilled
let x: Option<i32> = None;
x.is_some();
You can unwrap it if you want an error. Or use a helper function if there is a default to provide. But it explicitly makes clear that the function can fail, and leaves error handling to the consumer. The Python version gives no indication that something may go wrong.
I'd be surprised if you hadn't thought of this but have you thought about wrapping up the error handling logic in some macros?
Is this the price of not having exceptions?
I guess this is a matter of opinion but are you familiar with the school of thought (to which I belong) that claims that exceptions are worse than goto's? (And before anyone comes in to say that goto's are okay, I'm well aware that they make a lot of sense for certain things and I do use them for those things but they should not be the main flow control operation).