7 ms·

The backwards compatibility promise (as always) is really nice. Java/JVM is the only other language/platform that I can think of that does more or less the sam

The backwards compatibility promise (as always) is really nice. Java/JVM is the only other language/platform that I can think of that does more or less the same. Using both extensively by the way.

mseepgood 3y ago
Yes, I like to build my castles on solid ground rather than on quicksand.
greggyb 3y ago
Common Lisp has been standardized for longer than Java's life. Also in the lisp world, Clojure has a fastidious dedication to backward compatibility. Perl 5 has maintained backward compatibility (though I am not certain if it is 100% compatible) by putting changes behind flags.
germandiago 3y ago
C++ takes compatibility very serious. Though it has ABI stuff here and there you need to deal with due to its fully native AOT compilation nature.
- deepsun 3y ago
  Just curious, isn't Go compilation fully native? Java I know, it's technically interpreted (transpilation not compilation), but Go?
- pjmlp 3y ago
  Kind of, there are plenty of breaking changes as well, three that quickly come to mind, removal of exception specifications, std::auto_ptr<>() removal, and the new semantic changes due to the way <=> behaves.
  - germandiago 3y ago
    For the former two, breakages have replacements and are a vestige noone used for a long time. Besides that, compilers have switches to treat throw() as noexcept. As for the latter, those breakages are relatively rare.
    - pjmlp 3y ago
      Someone still has to write those replacements, and no, not all compilers have such switches. Besides that was only a quick set of examples, if I would bother going through my ISO copies, there would be a couple more to list.
      - germandiago 3y ago
        Do you still think those are breakages that get in the middle a lot?
        pjmlp 3y ago
        Depends on how lucky one happens to be, specially in large code bases, touched by dozens of consulting companies, and offshoring deliveries.
beezlewax 3y ago
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?
Tozen 3y ago
Many other languages give the backwards compatibility promise. For instance Vlang (https://vlang.io https://vlang.io), does as well. But in their case, they limit it to a 3 year backward compatibility promise, which kind of makes more sense (also due to them being in beta). It gives them more flexibility to make needed changes to the language, but enough stability to limit issues for users. Though in general, such more open languages are going to be more responsive to users and their requests/needs, because of how they are structured.
pjmlp 3y ago
Java/JVM have breaking changes from Java 9 onwards, and now deprecated stuff is actually removed, not left around until the end of universe.

The backwards compatibility promise (as always) is really nice. Java/JVM is the only other language/platform that I can think of that does more or less the same. Using both extensively by the way.

mseepgood 3y ago

Yes, I like to build my castles on solid ground rather than on quicksand.

greggyb 3y ago

Common Lisp has been standardized for longer than Java's life. Also in the lisp world, Clojure has a fastidious dedication to backward compatibility. Perl 5 has maintained backward compatibility (though I am not certain if it is 100% compatible) by putting changes behind flags.

germandiago 3y ago

C++ takes compatibility very serious. Though it has ABI stuff here and there you need to deal with due to its fully native AOT compilation nature.

deepsun 3y ago
Just curious, isn't Go compilation fully native? Java I know, it's technically interpreted (transpilation not compilation), but Go?
pjmlp 3y ago
Kind of, there are plenty of breaking changes as well, three that quickly come to mind, removal of exception specifications, std::auto_ptr<>() removal, and the new semantic changes due to the way <=> behaves.
- germandiago 3y ago
  For the former two, breakages have replacements and are a vestige noone used for a long time. Besides that, compilers have switches to treat throw() as noexcept. As for the latter, those breakages are relatively rare.
  - pjmlp 3y ago
    Someone still has to write those replacements, and no, not all compilers have such switches. Besides that was only a quick set of examples, if I would bother going through my ISO copies, there would be a couple more to list.
    - germandiago 3y ago
      Do you still think those are breakages that get in the middle a lot?
      - pjmlp 3y ago
        Depends on how lucky one happens to be, specially in large code bases, touched by dozens of consulting companies, and offshoring deliveries.

beezlewax 3y ago

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?

Tozen 3y ago

Many other languages give the backwards compatibility promise. For instance Vlang (https://vlang.io https://vlang.io), does as well. But in their case, they limit it to a 3 year backward compatibility promise, which kind of makes more sense (also due to them being in beta). It gives them more flexibility to make needed changes to the language, but enough stability to limit issues for users. Though in general, such more open languages are going to be more responsive to users and their requests/needs, because of how they are structured.

pjmlp 3y ago

Java/JVM have breaking changes from Java 9 onwards, and now deprecated stuff is actually removed, not left around until the end of universe.