[josefx]

> The community of python users, which include companies with ten year old unmaintained scripts, did not want it invest to transition until the absolute last second.

Try shipping python3 scripts to systems that only have python2 interpreters. Doesn't work very well unless you also start to ship the interpreter and all its dependencies. I learned my lesson and just avoid distributing any Python code to customers now.

[ric2b]

What language lets you ship scripts that use features of version X and also works on versions <X?

Docker tends to be the easy solution for all this stuff, and it's language agnostic.

> Doesn't work very well unless you also start to ship the interpreter and all its dependencies.

That basically applies to everything that isn't a statically linked binary.

[fnord123]

Agree with you here. If you try to deploy a C program to ancient centos then it can also fail with glibc being incompatible.

https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-...

[nonameiguess]

Much different from Python, though. As long as you compile your C program against the same version of libc you're running against, the program will still work, no matter how old the code. You just can't run a program that was compiled against an incompatible libc. A Python 2 interpreter can't run Python 3 code, and vice versa, no matter what, because the actual language changed.

[kazinator]

You can't always easily compile an old C program against the new C libraries you are running. Even if you can compile it, changes in libraries can break programs. E.g. say in the ancient library, memcpy with null pointer parameters worked, if the size was zero. The new library checks it and aborts. There are all sorts of issues like this.

Every time libraries and compilers advance, you're effectively porting all the existing code. You have to fix any build breakage, and re-validate everything.

Moreover, Python is a C program. Just get the old Python 2 C code and compile it against "the same version of libc you're running" and it will work, right? Where is the problem?

[josefx]

Why recompile it when the existing binary still works with the current runtime? At least on Linux the old version of memcpy will still be included in the runtime library to avoid this kind of issue.

[fnord123]

The point is that the code needs the runtime.

[josefx]

But it will run on a modern system if you compiled it against the CentOS version. I have a VM running to do just that. Trying to run Python 2 code on a modern runtime on the other hand will have the Python community feed your remains to the pigs.

[josefx]

> What language lets you ship scripts that use features of version X and also works on versions <X?

I didn't care about Python 3 features, but you can't run Python 2 code on a Python 3 interpreter either and the Python 2 interpreter was abandoned. Meanwhile you can run ancient JavaScript code on both old and modern systems, ancient C++ on both old and modern systems, ancient Java mostly on both old and modern systems, etc. .

> Docker tends to be the easy solution for all this stuff, and it's language agnostic.

I think I will rather go with statically linked binaries before I dump docker on unsuspecting users. Just the pain of getting that dependency whitelisted by their corporate IT makes my skin crawl.