Yep. I was interested in the post as I've always felt Django is python software "done right". I stopped reading when they started complaining about python 3.

Python 3 has been out for over 10 years now. Did OP really think Django was going to use python 2 forever? Frankly that's a selfish outlook, and I'd go as far as saying it's a cancer of software development.

Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually.

> Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually.

This mentality is the true cancer of software development IMO. Can you imagine the utter insanity and chaos if any other form of engineering worked this way? Programming languages are like protocols and standards: they are a common platform that people build on; simply deprecating them with no plan for backwards compatibility requires everything to be rebuilt, which represents a tremendous cost. Sometimes these changes are worth it, but outside of software, these are usually once-in-a-lifetime changes.

I can't think of any fundamental technical change between Python 2 and Python 3 that make this scale of disruption worthwhile. If the maintainers of Python don't want to maintain Python 2 anymore, they are completely free to make that decision, but it's a decision worth criticizing and complaining about. It is not a good thing for all software developers to be forced to rebuild the same sand castles every time the tide goes back out.

> Can you imagine the utter insanity and chaos if any other form of engineering worked this way?

You mean like how when I bought my house I had to bring the wiring up to code and replace the knob and tube?

This is how the rest of the world works. The time scales are simply longer.

> This is how the rest of the world works. The time scales are simply longer.

Which is exactly the point I'm making. Nobody is going to deprecate 120V power for the kinds of reasons that software platform deprecations happen.

But big changes do happen. In 1948, the west coast changed their power standard from 50Hz to 60Hz[1]. Or changes don't happen, Japan still has two standards[2]. Or, like metric in the US, it slowly changes but likely will never completely happen.

[1] https://gizmodo.com/before-1948-las-power-grid-was-incompati...

[2] https://en.wikipedia.org/wiki/Electricity_sector_in_Japan#Tr...

Sure, but the pace of these changes is significantly different. Clearly part of this is due to Moore's law; perhaps standards in aeronautical engineering shifted about as quickly during the transition from biplanes to supersonic jets as our software standards and frameworks are changing today.

But that's no reason to reflexively dismiss the very good and very interesting question of why one should have to largely rewrite a Django app in 2019 that does the same thing that it did in 2010, in a language that is virtually functionally equivalent in any respect that is relevant to that particular developer. Software does not inherently need to be as ephemeral as it is.

This is a scope problem. If thousands of people were constantly attacking your door's locks you better believe that locks would constantly be changing and that a house with older locks would need to have them upgraded.

Changes to physical items are costly and not affected by the same types of security scope that _any_ code connected to the internet is. The code in my decade old microwave has never needed to be upgraded and probably never will be upgraded, but it's also not under constant attack.

His Django app continued to run, he just couldn't make use of the most up-to-date features and security unless he upgraded.

I get the need for security updates. That’s why you use high level frameworks to write your application and update the rest of the stack that runs underneath. The issue is when parts of that stack are replaced with backwards-incompatible-but-functionally-equivalent parts, for reasons that have nothing to do with security.

But that's why you have to look at the maturity of the tech when first building it--sometimes you just don't know. Python 3 was first released in 2008. Python 2 EOL is 2020. If I built an app in 2010 using a Python 2 stack you have to know by 2019 you're going to have to rewrite it completely using a new stack or modify it heavily (assuming Django would move to Python 3 and be active 10 years later).

If you had built your page using static html there would be a lot less surface area of attack and a lot less maintenance. Even with Django, the amount of churn depends on which features you use.

You hear similar stories about people chasing the new Javascript framework treadmill. Some people stuck with Vanilla JS, others are still using jQuery.

I just don't see the real world being all that different. Blackboards still work just fine like they did 100 years ago. Some schools transitioned to marker boards, and some moved again to "smart boards." Many were forced along because repair/replacement supplies were harder and more expensive to find. I see the same thing with washing machines or people's favorite pen/pencil.

In fairness, I suspect the author would agree that it was a mistake to use Django in the first place. I think that's what he was trying to get at!

> Python 3 was first released in 2008. Python 2 EOL is 2020. If I built an app in 2010 using a Python 2 stack you have to know by 2019 you're going to have to rewrite it completely using a new stack or modify it heavily (assuming Django would move to Python 3 and be active 10 years later).

In 2010, the conventional wisdom was still, "nobody uses Python 3, there is no library support for Python 3 so just use Python 2". Django itself didn't support Python 3 until 2013.

In hindsight he can say it was a mistake, but it was glaringly obvious back then that Django, Python 2, or Python 3 wouldn't give you a situation where you would have minimal maintenance for the next 10 years because of the volatility already publicly discussed.

But maybe you're right that this isn't something people think enough about when choosing technologies and the author is trying to raise awareness.

Oh I don’t know... “star-star” is pretty cool... I tend to agree with the others who think this is a little too much bellyaching.

> Backward compatibility needs to be a thing, but not forever. Things need to be deprecated eventually.

That might not need to be the case. I guess we'll see: one of Rust's tenets is perpetual backwards compatibility. New features (and potential breaking changes) are opt-in with a per project configuration setting.

Doesn't JavaScript do it the same way?

The author acknowledges that some maintenance is necessary, especially for security updates. My reading of it was that his complaint is that in keeping up with the security upgrades, Django breaks other things.

This is true of a number of frameworks I've worked with. If you want security, you have to constantly stay on top of the other changes that the framework makers implement, often "fixing" things that aren't broken, removing features, or changing the way things work.

I don't know how practical it is, but it would be nice to see a framework where security updates and feature updates were separate things. One could keep one's site secure through updates without having to debug formerly working things every few months.

> I don't know how practical it is, but it would be nice to see a framework where security updates and feature updates were separate things. One could keep one's site secure through updates without having to debug formerly working things every few months.

This is more or less what an LTS release is. The problem as I see it is that, as the codebases diverge, it becomes more and more work for the dev teams to support what is now essentially two different products. And especially in the open source world, it seems futile to expect unpaid or low-paid contributors to continue to do extra work simply because someone else's dev team doesn't want to put in the work doing updates.

> My reading of it was that his complaint is that in keeping up with the security upgrades, Django breaks other things.

Django takes great pains to ensure that this isn't true. We don't backport anything other than bugfixes and security updates to releases. It's not like we suddenly introduce a new feature into a previous release that's backwards incompatible with your current code. If you're on the LTS release then you can be happy in upgrading Django to the latest point release with all the latest fixes.

And the Django project has finite resources. It cannot backport security fixes indefinitely which is why we have the LTS release in the first place. If you want something stable: sit on that for several years at a time, or spend your time backporting any security fixes yourselves.

Unfortunately software is a moving target, but Django tries to make it easy to upgrade from one LTS release to the next. The upgrading difficulty often comes from third party packages, which is hard to avoid in any framework or language.

Unfortunately it's not practical because the test matrix explodes. They would have to develop and test every security update on every previous version which is quite costly, especially if the codebase has diverged.

The best strategy is probably what many large distros like Ubuntu have adopted: designate only a few long term support (LTS) versions, and commit to supporting only those versions.

The only matrix i support now is latest release and master, not even LTS anymore because it quickly gets too old. I consider not updating my software to be tech debt: something I must do before adding a new feature. In return, my software is always up to date and ready for new features, except once in a year when I do the said upgrades.

There is a saying amongst growers of bonsai trees: A tree isn't "finished" until it is dead. In other words, it keeps growing and so you constantly have to keep working on it. You can't just think of a design, prune the tree and then say, "Oh, I'm done! Let it stay like this forever".

Software is exactly the same. Your needs may never changes, but the world around you does. You have no control of that and so you must constantly maintain your code -- even if there are no changes that you want.

It's not just Python or django. It's hasn't even possible to compile Ruby 1.8.7 with recent versions of GCC for at least a year (don't ask me how I know... :-P ). Starting a software project -- any project -- is a long term commitment. If you want it to survive, you need to care for it.

>I feel that. But on the other hand, without trying to sound too mean: what exactly does he expect?

It's not unreasonable to expect to be finished with software.

>For better or for worse, this is simply how software works.

This is false. The author has already fallen into this trap by using a programming language which is also subject to this, however.

>Things have to be updated. Unless you want to eschew security updates (which is not smart), there is never such a thing as a fully "finished" product.

There is such a thing as finished software, but I can understand why something such as a WWW framework wouldn't be. The WWW is ugly and misguided and inspires disgusting systems to accomodate it.

>Software maintenance is part of the job responsibilities.

When you have a project with no real design goals, apparently, I agree. Otherwise, you can remark on how a program achieves its goals and so is finished. That doesn't stop minor improvements or reworkings, but those would be entirely unnecessary.

>This post is particularly targeted at Django, but I feel that it applies to almost every web framework or piece of software

I agree, because, again, the WWW is a disgusting tangle of systems that encourages similarly disgusting systems.

One language I enjoy is Common Lisp. The standard hasn't changed in decades and there are many implementations. I can finish a library and then never need to touch it again. Python can't compare.

> For better or for worse, this is simply how software works.

This post is more or less a lament about that fact, not necessarily a complaint or gripe. Chris is a Sysadmin, and there’s a big difference in perspective between this and a developer of an app whose reason for being is THE APP. A Sysadmin needs to provide a bunch of services that are not the core revenue generator, and multiples of them, meaning that every internal app has this same kind of updating overhead. It becomes tiresome to have to keep all of them up to date all the time. We know that is a fact of life, but not all facts of life are fun and people like to blow off steam about that.