5 ms·

That's not my perception. For example, the language and standard library freeze is in 3 weeks (the beta release), and yet they are doing a complete redesign of

That's not my perception. For example, the language and standard library freeze is in 3 weeks (the beta release), and yet they are doing a complete redesign of the std::io module: http://discuss.rust-lang.org/t/psa-io-old-io/1403 http://discuss.rust-lang.org/t/psa-io-old-io/1403 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.

vhbit 12y ago
And still they have enough experience with existing API to accept it is much worse in long term perspective. With new API at least most annoying things will be solved.
- iamarock 12y ago
  I'm not criticizing the API overhaul, I'm criticizing the unrealistic release schedule rush.
  - Animats 12y ago
    That's a legitimate criticism. As of yesterday, how to convert "String" to "&str" still wasn't nailed down. (".as_string(), or "&[]"?). Things are far better than they were a month ago, though. 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/datetime.rs 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()) } This has generics and a closure, neither of which ought to be necessary. Despite all this generality, there are two copies of this code, one for time-zone aware and one for "naive" timestamps. The author of that module has misgivings about the structure. He writes "This is a bit verbose due to Rust's lack of function and method overloading, but in turn we get a rich combination of initialization methods." This is the best of the three date-time modules available; the other two won't even compile with the current build system and are abandoned. 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/" 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.
    - adamnemecek 12y ago
      > 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. 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?
      - Animats 12y ago
        Yes, there's a workaround, but that's not the point. So many layers of cruft in the early days of a language is worrisome. It took C++ two decades to dig itself into a hole this deep. Is this the price of not having exceptions?
        ecnahc515 12y ago
        No, this is the price of choosing to make it impossible to not explicitly check an error, even if your going to ignore any potential error, at least you know it's impossible to accidentally write code which blindly forgets about the potential error cases.
        pcwalton 12y ago
        I disagree that it's cruft; to me null pointers feel like cruft, because they silently blow up when you dereference them. The code above handles the None case explicitly, which is what any systems code should be doing.
        adamnemecek 12y ago
        > 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).
        Animats 12y ago
  - pcwalton 12y ago
    Rust has been in development for over five years. It is, objectively, one of the least rushed major open source projects ever. What may look like rushed decisions, such as I/O stability, are actually the culmination of months of RFC process and years of experience before that.
steveklabnik 12y ago
The discussion about reforming IO has been going on since December 12: https://github.com/rust-lang/rfcs/pull/517 https://github.com/rust-lang/rfcs/pull/517 Furthermore, consider that many programming languages have gotten popular post-1.0, so if anything, they had _even less_ experience than we will have.
brson 12y ago
You are right that there are risks in making big changes at this stage, but my understanding is that the I/O redesign is not as radical as it would seem, and it resolves long-standing issues. 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.
aturon 12y ago
The renaming to "old_io" is purely to make updating code clearer easier -- it does not indicate a massive redesign. 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.
coldtea 12y ago
>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. 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.

vhbit 12y ago

And still they have enough experience with existing API to accept it is much worse in long term perspective. With new API at least most annoying things will be solved.

iamarock 12y ago
I'm not criticizing the API overhaul, I'm criticizing the unrealistic release schedule rush.
- Animats 12y ago
  That's a legitimate criticism. As of yesterday, how to convert "String" to "&str" still wasn't nailed down. (".as_string(), or "&[]"?). Things are far better than they were a month ago, though. 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/datetime.rs 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()) } This has generics and a closure, neither of which ought to be necessary. Despite all this generality, there are two copies of this code, one for time-zone aware and one for "naive" timestamps. The author of that module has misgivings about the structure. He writes "This is a bit verbose due to Rust's lack of function and method overloading, but in turn we get a rich combination of initialization methods." This is the best of the three date-time modules available; the other two won't even compile with the current build system and are abandoned. 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/" 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.
  - adamnemecek 12y ago
    > 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. 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?
    - Animats 12y ago
      Yes, there's a workaround, but that's not the point. So many layers of cruft in the early days of a language is worrisome. It took C++ two decades to dig itself into a hole this deep. Is this the price of not having exceptions?
      - ecnahc515 12y ago
        No, this is the price of choosing to make it impossible to not explicitly check an error, even if your going to ignore any potential error, at least you know it's impossible to accidentally write code which blindly forgets about the potential error cases.
      - pcwalton 12y ago
        I disagree that it's cruft; to me null pointers feel like cruft, because they silently blow up when you dereference them. The code above handles the None case explicitly, which is what any systems code should be doing.
      - adamnemecek 12y ago
        > 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).
        Animats 12y ago
- pcwalton 12y ago
  Rust has been in development for over five years. It is, objectively, one of the least rushed major open source projects ever. What may look like rushed decisions, such as I/O stability, are actually the culmination of months of RFC process and years of experience before that.

steveklabnik 12y ago

The discussion about reforming IO has been going on since December 12: https://github.com/rust-lang/rfcs/pull/517 https://github.com/rust-lang/rfcs/pull/517 Furthermore, consider that many programming languages have gotten popular post-1.0, so if anything, they had _even less_ experience than we will have.

brson 12y ago

You are right that there are risks in making big changes at this stage, but my understanding is that the I/O redesign is not as radical as it would seem, and it resolves long-standing issues. 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.

aturon 12y ago

The renaming to "old_io" is purely to make updating code clearer easier -- it does not indicate a massive redesign. 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.

coldtea 12y ago

>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. 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.