6 ms·

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

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.
    - Manishearth 10y ago
      Rust has rfcs, and many of the "breaking changes" are in places where the implementation didn't follow the RfC. Others were in things that were never intended to compile. Its effectively the same thing.
    - masklinn 10y ago
      > methodonpointerotpointer is not a breaking change if you read the specs. It's not a breaking change according to Go's definition of breaking changes, by which Rust hasn't had any breaking change either. > Rust doesn't even have a formal language specification. Neither does Go, the spec is not a formal specification (and the first phrase of the intro states that it's a reference manual).
- pcwalton 10y ago
  Rust has the same policy. It might appear differently because we're very up front about any change that might possibly break any code, even theoretically. We don't make any changes that we think actually break code, except for blatant bug fixes. Go has made changes post-1.0 that were more aggressive than anything Rust has done, such as changing the size of int.
  - themihai 10y ago
    I'm sorry to say but you must be delusional. Can you list the these `aggressive` breaking changes? There were only 7 releases since go1 and I fail to find any breaking change in the language specification. On the other side each Rust release has a fat list with "BREAKING CHANGES". Many Rust packages only work with specific Rust versions(i.e. nightly). The rust ecosystem(std lib, tools etc) is also way behind Go in terms of stability. Why do you need rustup if Rust is so backward compatible? I'm not saying that Go is a better language than Rust but the its ecosystem and dev experience is definitely superior.
    - steveklabnik 10y ago
      > Why do you need rustup if Rust is so backward compatible? For one, testing on various versions of Rust. For example, I have a kernel project that's pinned to a particular nightly version, while the rest of my projects build on stable. Rustup makes this Just Work.
      - themihai 10y ago
        Well, that's my point! You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. I might be mistaken but my feeling is that most of the rust devs are using the nightly version thus the reason of a tool to debug/test different versions.
        pcwalton 10y ago
        > You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. Can you specify, in particular, what you think Rust is not doing that it should be doing?
madmax96 10y ago
I think that Java has (on the whole) been very stable, but as steveklabnik pointed it, it also has had breaking changes. But considering Java's age and the quantity of these changes, I'd say it's been exceptionally good (especially since there's some fairly hefty pre 1.5 stuff that will still compile and run.) Clojure, Go, JavaScript, and Scheme come to mind. I don't think it's fair to compare a language's breaking changes to a library's. I expect different levels of stability depending on the library, but with languages I expect the same level of stability. Rust __has__ been very good at dealing with breaking changes, yes. I'm stating that I don't like breaking changes in a language. Breaking changes in a 1.0 > language are something that should be exceedingly rare.

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.
  - Manishearth 10y ago
    Rust has rfcs, and many of the "breaking changes" are in places where the implementation didn't follow the RfC. Others were in things that were never intended to compile. Its effectively the same thing.
  - masklinn 10y ago
    > methodonpointerotpointer is not a breaking change if you read the specs. It's not a breaking change according to Go's definition of breaking changes, by which Rust hasn't had any breaking change either. > Rust doesn't even have a formal language specification. Neither does Go, the spec is not a formal specification (and the first phrase of the intro states that it's a reference manual).
pcwalton 10y ago
Rust has the same policy. It might appear differently because we're very up front about any change that might possibly break any code, even theoretically. We don't make any changes that we think actually break code, except for blatant bug fixes. Go has made changes post-1.0 that were more aggressive than anything Rust has done, such as changing the size of int.
- themihai 10y ago
  I'm sorry to say but you must be delusional. Can you list the these `aggressive` breaking changes? There were only 7 releases since go1 and I fail to find any breaking change in the language specification. On the other side each Rust release has a fat list with "BREAKING CHANGES". Many Rust packages only work with specific Rust versions(i.e. nightly). The rust ecosystem(std lib, tools etc) is also way behind Go in terms of stability. Why do you need rustup if Rust is so backward compatible? I'm not saying that Go is a better language than Rust but the its ecosystem and dev experience is definitely superior.
  - steveklabnik 10y ago
    > Why do you need rustup if Rust is so backward compatible? For one, testing on various versions of Rust. For example, I have a kernel project that's pinned to a particular nightly version, while the rest of my projects build on stable. Rustup makes this Just Work.
    - themihai 10y ago
      Well, that's my point! You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. I might be mistaken but my feeling is that most of the rust devs are using the nightly version thus the reason of a tool to debug/test different versions.
      - pcwalton 10y ago
        > You shouldn't need to test various versions of Rust if you there is a strong backward compatibility policy. Can you specify, in particular, what you think Rust is not doing that it should be doing?

madmax96 10y ago

I think that Java has (on the whole) been very stable, but as steveklabnik pointed it, it also has had breaking changes. But considering Java's age and the quantity of these changes, I'd say it's been exceptionally good (especially since there's some fairly hefty pre 1.5 stuff that will still compile and run.) Clojure, Go, JavaScript, and Scheme come to mind. I don't think it's fair to compare a language's breaking changes to a library's. I expect different levels of stability depending on the library, but with languages I expect the same level of stability. Rust __has__ been very good at dealing with breaking changes, yes. I'm stating that I don't like breaking changes in a language. Breaking changes in a 1.0 > language are something that should be exceedingly rare.