Hacker News Reader

Comment by rickette | Hacker News Reader

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.

View on HN

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.

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.

Just curious, isn't Go compilation fully native? Java I know, it's technically interpreted (transpilation not compilation), but Go?

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.

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.

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.

Do you still think those are breakages that get in the middle a lot?

Depends on how lucky one happens to be, specially in large code bases, touched by dozens of consulting companies, and offshoring deliveries.

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

Many other languages give the backwards compatibility promise. For instance Vlang (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.

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

Pretty sure Rust has this too right?

Rust is definitely not backwards-compatible in the sense that Go is backwards-compatible.

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.

I think std async is about as good an example as any.

Do you mean async-std as in the 3rd party crate?

The third-party crate which is not part of the language? https://github.com/async-rs/async-std

Both are too young to have it evaluated fairly. It is easy to be backwards compatible on a short term.

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?

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.

It's never backwards compatibility, its that a lot of code depends on features that are not present in older releases.

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.

Go is more than 10 years old, that's certainly old enough.

Reply on news.ycombinator.com