Brazil have something like that: Up to 4 children, you get about 1/4 of the minimum pay from the government for each. There are some caveats, though: The children must be in school, they can't fail a year, children which reach adult age (18) do not count/get paid for anymore, and the family monthly salary can't exceed about 75% of the minimum pay[1] to be eligible.
While this somewhat help lower paid families, we still have a huge number of men that just leave their families once kids appears and leave a single mother to raise the kids -- which have their own issues.
[1] I may be a bit off in the values, but you get the idea.
That's one way to think about numbers and not about the persons.
I believe most of countries have orphanages already -- and what you're suggesting already exists in some countries (I do believe we still have that in Brazil).
While that could increase the number of people, orphanages are not great places to raise a child (with rare exceptions). Imagine you growing up with a large group of other child, and nobody actually take the time to take care of you. What kind of person would you be today?
(Just to be sorta pedantic) I don't think it's the version 1.x that promotes backward compatibility, but editions.
In 2016, you could call your function `fn async(...) { ... }` without any issues, and you can still compile this code with the modern version of rustc. If you want to use the async features of Rust, you need to change your edition to at least 2018, which brings breaking changes in the language.
And you can have a project that mixes those editions, and cargo will correctly use the edition asked for each crate.
(So, I guess the ideal world would to first look at the package management in Python, and *then* try to introduce breaking changes. And I'm withholding how much I'm angry at the PSF for postponing having a decent package manager for 20 years and investing in removing the GIL and adding JIT.)
Not meaning to apologize for Python here, but you have significantly more ability to segregate “editions” when you statically compile code.
All the more reason to take a breakage very seriously. This is even worse than the walrus operator. At least I can ignore that. This breaks working code for some notion of purity.
Code compilation doesn't really have much to do with it. Python already has a somewhat similar ability - opting into certain language features of python on a file-by-file basis - using __future__[0]. It'd be pretty easy to add something like Rust editions by looking for a special statement in the file. And to make it more convenient, put it in the __init__.py and have it be transitive to the module.
Imagine you wake up one day, and see that you get a bunch of code review requests 'cause the old maintainer simply said "This guy is the owner of this now".
(I'm pretty sure Mark is fine with this, and Guido already explained the situation to him, but kinda funny, nonetheless.)
The "Renamed To" was bothering me (like some other posters mentioned), and then it hit me why:
Forks of large projects happen when something bad is going with the source (why fork something huge when things are going ok?), and marks the source as poisoned.
Renamed means... It just changed name, everything is already, nothing to see here...
Sure there is the mindshare on the name but people in IT for long knows what means when a fork of this size means.
