Honestly, I have been thinking about the same topic for some time, and I do realize that direct files could be faster.
In my (hypothetical, 'cause I never actually sat down and wrote that) case, I wanted the personal transactions in a month, and I realized I could just keep one single file per month, and read the whole thing at once (also 'cause the application would display the whole month at once).
Filesystems can be considered a key-value (or key-document) database. The funny thing about the example used in the link is that one could simply create a structure like `user/[id]/info.json` and directly access the user ID instead of running some file to find them -- again, just 'cause the examples used, search by name would be a pain, and one point where databases would handle things better.
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.)
In my (hypothetical, 'cause I never actually sat down and wrote that) case, I wanted the personal transactions in a month, and I realized I could just keep one single file per month, and read the whole thing at once (also 'cause the application would display the whole month at once).
Filesystems can be considered a key-value (or key-document) database. The funny thing about the example used in the link is that one could simply create a structure like `user/[id]/info.json` and directly access the user ID instead of running some file to find them -- again, just 'cause the examples used, search by name would be a pain, and one point where databases would handle things better.