Comment by munificent | Hacker News Reader

Comment by munificent | Hacker News Reader

Parent Full thread

> But, it comes from a promise to avoid a version upgrade debacle in the style of Python 3.

There is a very wide middle ground between C++'s "Your horrific unsafe code from the 80s still compiles" and Python's "We changed the integer values common operations on strings return at runtime with absolutely no way to statically tell how to migrate the code".

In Dart, we moved to a sound static type system in 2.0, moved to non-nullable types in 2.13 (sound and defaulting to non-nullable!), and removed support for the pre-null safety type system in 3.0. We brought almost the entire ecosystem with us.

Granted, our userbase is much smaller than C++'s and the average age of a given Dart codebase is much younger.

But you can deprecate and remove old features without causing a decade of misery like Python did. You just need good language support for knowing which version of the language a given file is targeting, good static typing support, and good automated migration tooling. None of those is rocket science.

> But you can deprecate and remove old features without causing a decade of misery like Python did. You just need good language support for knowing which version of the language a given file is targeting, good static typing support, and good automated migration tooling. None of those is rocket science.

That's way easier to do in a naturally statically-typed language though.

Yes, which C++ is.

Except there is only one implementation, with language design and implementation developed together.

C++, Java and .NET are now all living through "decade of misery like Python did", exactly because not everyone is jumping into the latest versions of the languages and ecosystem changes.

Isn't this a problem only if you manage your dependencies by source rather than "compiled"?

That is, in Java you may not be able to compile old code with new javac, but the class file format is still understood by the JVM. So your old .jar still works.

I believe it is the same in C++ with the .so. I don't know about .NET.

In Python however, I don't think the .pyc were compatible between Python2 and Python3.

Your jar file only works if what it expects to find it is still there, it will crash and burn otherwise.

Same applies to other examples.

I'm not sure to understand.

You mean if your jar depends on other stuff?

Of course.

The way the bytecode is executed, the standard library, possible changes in GC and JIT implementation, other 3rd party libraries.

For example, if the jar code has a call to Thread.stop() and is loaded in Java 11 or later, when it comes to actually call that method you will get a java.lang.NoSuchMethodError exception.

Got it, thanks.

Reply on news.ycombinator.com