5 ms·

Pretty sure Rust has this too right?

• kiitos 3y ago
  Rust is definitely not backwards-compatible in the sense that Go is backwards-compatible.
  • stusmall 3y ago
    How so? What breaking changes have you hit? It has the same guarantee and takes it extremely seriously. The only code I know of that compiled on a stable post-1.0 compiler but broke was because of bugs, even those cases are rare.
    • kiitos 3y ago
      I think std async is about as good an example as any.
      • stusmall 3y ago
        Do you mean async-std as in the 3rd party crate?
      • stouset 3y ago
        The third-party crate which is not part of the language? https://github.com/async-rs/async-std https://github.com/async-rs/async-std
  • kaba0 3y ago
    Both are too young to have it evaluated fairly. It is easy to be backwards compatible on a short term.
    • kramerger 3y ago
      Not really. Rust have had backward compatibility problems already during its young life. Why do you think you need to specify release and nightly to successfully build some projects?
      • masklinn 3y ago
        Because the project is using nightly features? Which are specifically not guaranteed to remain or be stabilised? That’s like complaining that the exp packages are not stable.
      • eptcyka 3y ago
        It's never backwards compatibility, its that a lot of code depends on features that are not present in older releases.
      • stusmall 3y ago
        That is because features might be feature complete and usable, but not consider stable yet and thus not part of stable builds. This because rust takes backwards compatibility seriously, it isn't an example of it breaking it.
    • kiitos 3y ago
      Go is more than 10 years old, that's certainly old enough.