> It's kind of disappointing that developers aren't self-aware enough to understand that they are essentially screwing themselves by not moving quickly in dropping "legacy" support.
I think the part that might be missing from your line of reasoning is context: For professionals and entrepreneurs programming isn't a hobby, it's a business.
The decision to stay with 2.x isn't about not being self-aware. It's about being serious about your business. Business has nothing to do with self-awareness. It would be irresponsible to send your organization down a path that could result in a huge setback.
If you are self-funded this could absolutely kill you. If you are in a competitive environment where time to market is crucial (who isn't) this could kill you. If you have investors who expect you to make responsible decisions, they could kill you.
How are you going to explain the decision to go to 3.x when the fertilizer hits the ventilator and you realize there are three choices in front of you:
1- Redo your entire codebase to migrate down to 2.x.
2- Launch a new project to rewrite the 2.x libraries you need.
This could take one week or one year.
3- Shut it down because you don't have enough cash to deal
with having made the wrong decision.
And, here's the kicker: You won't know until you hit that wall. Sure, you can do an initial dependencies survey. And hope you went deep enough. By definition, you will have no way to check dependencies you don't know about at the start of the project.
The bottom line is that in the context of a real business --not a hobby-- sticking with 2.x is probably the only responsible choice for a huge number of organizations. I really think the Python leaders made a mistake in not coming up with a smooth on-ramp onto the various ideas in 3.x. I do understand that some things need to be broken sometimes. In the real world you can only break so much of a codebase before people avoid it like the plague.
Here's the other reality: The customer doesn't give a damn whether you are using 2.x, 3.x, Python, Lisp, PHP or assembler. They buy your product or use your service because of the value they derive from it. For the vast majority of businesses and customers this has nothing whatsoever to do with the technology choices you make behind the scenes. If this fact isn't obvious, study the history of a number of prominent startups and you'll find support for this idea.
It's easy to fall back on engineering think and forget reality. I do it all the time. Over the years I've become better at avoiding thinking like that. Like wanting to build a product without doing market research and, a year later, finding out the hard way nobody wants it.
I'm not criticizing you here. I am simply pointing out something we all do from time to time.