It's comments like this that make me very sad for the software industry as a whole.
No, he's not being reckless and he's not putting people in danger. The people who make breaking changes to languages, APIs, operating systems and libraries are the ones that put people in danger and that cause others to stop upgrading because they quite reasonably fear breaking changes that could have far reaching consequences.
The price of backwards incompatibility is poorly understood.
While I agree that in general we should care more about backwards compatibility, don't put the blame on the maintainers for bad choices in life-critical domains. Most domains are not life-criticial and it's entirely reasonable to make and meet a set of compatibility guarantees which applies to the domains you're working in.
I think you just relegated python to the status of 'toy language'.
But that's the wrong attitude. Just like everything will sooner or later connected to the internet, which is why it matters that it is secure, with 'software is eating the world' as pretty much the mantra of HN you should realize that any piece of software, no matter how trivial has the potential to affect lives and sometimes in the most direct way with the ultimate price - of someone else's life - as the consequence of our collective failure.
And that's because of the very nature of software: it gets re-used all the time. One persons application is another persons library, one persons application is another persons service and so on.
Leaky abstractions are bad enough, leaky broken abstractions can sooner or later turn out to be dangerous.
Of course whoever deploys the software has the responsibility to check it for suitability. But in principle any language, OS or library has the potential to be applied in ways the original author did not foresee and if that potential can extend to life critical or life affecting purposes then that should come with a similar standard of care.
How many machine learning systems are written in Python? How many of those make decisions every day regarding people's lives, some of those life critical? Are you seriously suggesting that all those people made the wrong decision in picking the language the application is written in?
If so then you are most likely at odds about this with just about every developer out there who - rather than arguing with their manager about whether language 'x', 'y' or 'z' is suitable for the job will simply be told what language is on the menu and to do the job in that one based on availability of programmers and whatever is 'hip' at the moment. These decisions are not necessarily made in the most rational manner and whether you agree or disagree with that in principle it is the reality that we live in.
And so 'toy' languages such as Python, PHP, Perl, Visual Basic, FileMaker and so on are all going to be used for mission critical stuff, whether you add a disclaimer or not.
Better be aware of that before you throw your brainchild out into the world: you own it.
My responsibility is to meet whatever guarantees I make when I publish a tool, and to open source the code if I plan to stop maintaining it such that it no longer meets the original guarantees.
If you want to lay at my feet the consequences of everyone who chooses to use it, whether it's an individual dev or some executive mandating its use to their whole org, I think you need to reconsider your perspective.
This is the same stupidity you see in hospitals, with medical equipment running Windows 7 or older. The companies knew when they sold the equipment that it have a service life beyond the EOL date of the OS, yet make no plans to provide updates. The customers where also given all the details, to ask about support lifecycle before buying, and apparently also don’t care.
The sad part about the software industry is how little some people care about providing their customers with the updates and support plan they should be entitled to.
Now a lot of python stuff isn't really that mission or safety critical. So, a hopelessly outdated red hat server that hasn't been updated in years running some software developed over a decade ago may be convenient to keep up and running but if it's mission critical you could have acted by now. The good news is, you haven't updated in years in any case so why start caring about that now? Either way, it's your problem; own it and deal with it or not.
The source and binaries are still there and will still work a decade down the road. A lot of banks do just fine running software written in languages that stopped being fashionable half a century ago, where the developers have long retired/died, suppliers have long disappeared. Running their stuff on (typically emulated by now) hardware and OS that has gone out of production decades before the end of last century. Same thing. If push comes to shove, you can pay people to fix things for you. Banks do this all the time. But expect to pay for the privilege. Or just fix it properly, finally.
