4 ms·

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

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

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