13 ms·

Super exciting! I followed Rust at the beginning and I was pleased with the design goals of the language. However, I wasn't thrilled with the pre-1.0 documenta

Super exciting! I followed Rust at the beginning and I was pleased with the design goals of the language. However, I wasn't thrilled with the pre-1.0 documentation, and even after 1.0 there were breaking changes to the language. Hopefully this is a sign of Rust's maturity. I'll have to look at it again:>) EDIT: s/from/at/

steveklabnik 10y ago
Which post-1.0 breaking changes were you worried about? This is technically correct, but we've managed it in a way that's been hopefully painless to deal with, and the community survey seemed to agree.
- madmax96 10y ago
  The compiler has been fantastic emitting warnings about future language changes and I have appreciated it. The Rust compiler's messages (in general) are some of the highest quality I've seen, actually. The Rust Devs have done a superb job at documenting the changes. I'm more complaining that breaking changes to a non-beta language leave a bad taste in my mouth. Sure, they do have to happen sometimes, but it seems that this should be rarer than it has been so far with Rust. So I haven't worried about anything per se, but breaking changes are mildly irritating to me. Without a doubt the utility value of some of these changes has been worth it (specifically RFC 1214, which was ironically one of the most major and definitely necessary). I'm not involved enough to be able to speak about other changes. EDIT: I should also add that the software I work on professionally doesn't use any language that Rust competes with directly. Rust doesn't offer me professional utility so it's easy for me to complain about one thing and ignore all the benefits of Rust. If I were in a situation where I was contemplating using C++, Rust, or maybe Go, I think I would still choose Rust. It's far ahead of its competitors and gets a lot of things right.
  - steveklabnik 10y ago
    Cool, thanks. I mostly want to make sure we don't have any blind spots here; this is an issue we care about deeply. I think it's also important to remember that even languages which are known for "no breaking changes" do introduce breaking changes. Take Java for example, known for being an exemplar in this space. > However, implementation of some Java SE 8 features required changes that could > cause code that compiled with Java SE 7 to fail to compile with Java SE 8. http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html http://www.oracle.com/technetwork/java/javase/8-compatibilit... Especially in a statically-typed language, technically breaking changes are a fact of life. The key is to make them as minimal as possible, so that you don't struggle to update. (Oh, and glad to hear you like the errors: we're actually working on making them even better. Elm is really leading the way here...)
    - madmax96 10y ago
      Thanks for the response! I'm excited to see what you all do with the errors:) The UX of compilers have been improving dramatically lately...
      - mastax 10y ago
        If you're interested in the nitty gritty, there's some info in this PR: https://github.com/rust-lang/rust/pull/32756 https://github.com/rust-lang/rust/pull/32756 Though Steve may be talking about some newer work that I haven't heard of yet.
        steveklabnik 10y ago
        There's also stuff like this: https://github.com/rust-lang/rust/pull/34789 https://github.com/rust-lang/rust/pull/34789 In general, Jonathan and Niko are working on it :)
      - moosingin3space 10y ago
        Between Rust's and Elm's error messages, Go's focus on compilation speed, and even GCC's improvements in diagnostics, I'm really enjoying this focus on developer UX I see. It's made me more UX-conscious in my own tools.
  - Cshelton 10y ago
    I'm curious, do you have a language in mind that has been better than Rust as far as breaking changes go after the 1.0 stable release? An example? Rust has been far above most languages/libraries that I've found in dealing with breaking changes. The complaint here seems pretty empty to me. (Complaining for the sake of complaining)
    - themihai 10y ago
      Go has better backward compatibility.(i.e. no breaking change after 1.0)
      - steveklabnik 10y ago
        This is not true: > Although we expect that the vast majority of programs will > maintain this compatibility over time, it is impossible to > guarantee that no future change will break any program. https://golang.org/doc/go1compat https://golang.org/doc/go1compat It's extremely similar to our attitude, and that of Java, etc: > Of course, for all of these possibilities, should they arise, > we would endeavor whenever feasible to update the specification, > compilers, or libraries without affecting existing code. And they have in fact made such a change: https://golang.org/doc/go1.4#methodonpointertopointer https://golang.org/doc/go1.4#methodonpointertopointer This isn't a bad thing! My point is as I said below: every language includes some small breaking changes, even if the goal is to have very, very few of them.
        themihai 10y ago
        methodonpointerotpointer is not a breaking change if you read the specs. Rust doesn't even have a formal language specification.
        steveklabnik 10y ago
        Sure. My point is that this is similar to what we guarantee: the compiler used to compile some code, and now it won't. As they say, "It has therefore been disallowed in Go 1.4, which is a breaking change, although very few programs will be affected." Our breaking changes have been similar.
sochihi 10y ago
what's exciting in that?

steveklabnik 10y ago

Which post-1.0 breaking changes were you worried about? This is technically correct, but we've managed it in a way that's been hopefully painless to deal with, and the community survey seemed to agree.

madmax96 10y ago
The compiler has been fantastic emitting warnings about future language changes and I have appreciated it. The Rust compiler's messages (in general) are some of the highest quality I've seen, actually. The Rust Devs have done a superb job at documenting the changes. I'm more complaining that breaking changes to a non-beta language leave a bad taste in my mouth. Sure, they do have to happen sometimes, but it seems that this should be rarer than it has been so far with Rust. So I haven't worried about anything per se, but breaking changes are mildly irritating to me. Without a doubt the utility value of some of these changes has been worth it (specifically RFC 1214, which was ironically one of the most major and definitely necessary). I'm not involved enough to be able to speak about other changes. EDIT: I should also add that the software I work on professionally doesn't use any language that Rust competes with directly. Rust doesn't offer me professional utility so it's easy for me to complain about one thing and ignore all the benefits of Rust. If I were in a situation where I was contemplating using C++, Rust, or maybe Go, I think I would still choose Rust. It's far ahead of its competitors and gets a lot of things right.
- steveklabnik 10y ago
  Cool, thanks. I mostly want to make sure we don't have any blind spots here; this is an issue we care about deeply. I think it's also important to remember that even languages which are known for "no breaking changes" do introduce breaking changes. Take Java for example, known for being an exemplar in this space. > However, implementation of some Java SE 8 features required changes that could > cause code that compiled with Java SE 7 to fail to compile with Java SE 8. http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html http://www.oracle.com/technetwork/java/javase/8-compatibilit... Especially in a statically-typed language, technically breaking changes are a fact of life. The key is to make them as minimal as possible, so that you don't struggle to update. (Oh, and glad to hear you like the errors: we're actually working on making them even better. Elm is really leading the way here...)
  - madmax96 10y ago
    Thanks for the response! I'm excited to see what you all do with the errors:) The UX of compilers have been improving dramatically lately...
    - mastax 10y ago
      If you're interested in the nitty gritty, there's some info in this PR: https://github.com/rust-lang/rust/pull/32756 https://github.com/rust-lang/rust/pull/32756 Though Steve may be talking about some newer work that I haven't heard of yet.
      - steveklabnik 10y ago
        There's also stuff like this: https://github.com/rust-lang/rust/pull/34789 https://github.com/rust-lang/rust/pull/34789 In general, Jonathan and Niko are working on it :)
    - moosingin3space 10y ago
      Between Rust's and Elm's error messages, Go's focus on compilation speed, and even GCC's improvements in diagnostics, I'm really enjoying this focus on developer UX I see. It's made me more UX-conscious in my own tools.
- Cshelton 10y ago
  I'm curious, do you have a language in mind that has been better than Rust as far as breaking changes go after the 1.0 stable release? An example? Rust has been far above most languages/libraries that I've found in dealing with breaking changes. The complaint here seems pretty empty to me. (Complaining for the sake of complaining)
  - themihai 10y ago
    Go has better backward compatibility.(i.e. no breaking change after 1.0)
    - steveklabnik 10y ago
      This is not true: > Although we expect that the vast majority of programs will > maintain this compatibility over time, it is impossible to > guarantee that no future change will break any program. https://golang.org/doc/go1compat https://golang.org/doc/go1compat It's extremely similar to our attitude, and that of Java, etc: > Of course, for all of these possibilities, should they arise, > we would endeavor whenever feasible to update the specification, > compilers, or libraries without affecting existing code. And they have in fact made such a change: https://golang.org/doc/go1.4#methodonpointertopointer https://golang.org/doc/go1.4#methodonpointertopointer This isn't a bad thing! My point is as I said below: every language includes some small breaking changes, even if the goal is to have very, very few of them.
      - themihai 10y ago
        methodonpointerotpointer is not a breaking change if you read the specs. Rust doesn't even have a formal language specification.
        steveklabnik 10y ago
        Sure. My point is that this is similar to what we guarantee: the compiler used to compile some code, and now it won't. As they say, "It has therefore been disallowed in Go 1.4, which is a breaking change, although very few programs will be affected." Our breaking changes have been similar.

sochihi 10y ago

what's exciting in that?