4 ms·
Definitely not with Python. I'm currently maintaining a Python application and every minor version update for the language or even some of the frameworks involv
by Yoric 3y ago
Definitely not with Python. I'm currently maintaining a Python application and every minor version update for the language or even some of the frameworks involved comes as a high-stress process with numerous potential breakages.
- criddell 3y agoSure, but if you don’t keep moving to the new version, your application will continue to work for the foreseeable future, no? It wouldn’t surprise me to hear there are still some Python 2.7 holdouts.
- tgv 3y agoI've got an inherited Django project that still runs in 2.7 in a container. One day, I'll get the opportunity to rewrite it into something more suited to the task, and that'll be the end of 2.7 for me, but for now, it still does its thing.
- TeddyDD 3y agoBut then you have to keep old interpreter installed and you won't benefit from improvement in new versions of the interpreter. Your old Go code not only will work with new versions of the compiler - it probably will run faster.
- usrbinbash 3y agoI'm certainly not gonna defend Python here, but... >But then you have to keep old interpreter installed ...thanks to `pyenv` that really is a solved problem, even outside containerized environments.
- deleted 3y ago[deleted]
- cpuguy83 3y agoThis is incorrect. Go does make breaking changes all the time. I've seen it. I've helped maintain stdlib forks because of breakages. Still compiles is not the same thing as "works".
- crabbone 3y agoNot at all. Python 3.7 and older cannot be even built on current Linux + GCC. Python has few important system dependencies s.a. libffi and libssl that since changed major versions and aren't compatible with the interfaces used by Python 3.7 (what happens in Python 2.7 world -- heaven only knows). Python has no standard. There's no implementation of Python that say "we support versions X, Y and Z" of Python. It just keeps going and as the platform changes, it changes too. Old versions lose support relatively quickly. Three or four years if memory serves. If you go beyond that horizon, things start to fall apart, the further you go, the more likely it just be too hard to fix. Compare this to C, where compilers typically support all C standards up to something moderately recent. Your C89 code would compile and work today to the extent guaranteed by the standard. Actual programs will have experienced bitrot of course. Same reason: system interface changes, but, unlike in Python, those aren't part of the language.
- usrbinbash 3y ago> Not at all. Python 3.7 and older cannot be even built on current Linux + GCC. They can still be built in a suitable build environment (which is easy eg. with a container, and it is trivially easy to install a python 3.7 environment on a current linux, using precompiled binaries, without impacting the systems current python version, thanks to `pyenv` pyenv install 3.7.17 In fact I could install all the way down to 3.0.1 if I wanted (and ofc Python2 versions).
- crabbone 3y agoThat's like saying that Mac Lisp still works because you can put soldering iron to work and resurrect on of the two remaining Lambdas in existence. The whole point of what I said is that it doesn't work on modern systems. If you emulate old systems where it worked, then it's a nobrainer that it will work. Like, what are you even trying to prove with this?
- Yoric 3y agoProbably? At the expense of not being able to update too much the OS running the thing within Docker, which by itself comes with a security risk.