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.)
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.
> not all code can be easily updated to conform to safety rules (e.g., it’s old and not understood, it belongs to a third party that won’t allow updates, it belongs to a shared project that won’t take upstream changes and can’t easily be forked).
I have to say, this sentence annoys the heck out of me.
Old code that can't be understood needs to be rewritten anyway. And since you're rewriting, you can apply the safety rules -- which would be better anyway.
If the code belongs to a third party and they don't want to update, it means the third party is playing against you -- or, worse, that they control how you're going to move forward. It's in your best interest, in this case, to rewrite the third party dependency as soon as possible, and since you're rewriting, you can apply the safety rules -- which would be better anyway.
If the code is shared and the upstream does not accept patches and -- worse -- doesn't support forks, then you have an issue with the upstream anyway and -- guess what -- you'd be better rewriting it anyway.
All those issues are managerial issues, not software issues. Management decided that it is better to be stuck than moving forward. And they can happen with any languages, not just C++.
Adding these things as "we can't be totally safe" are like "I can't jog every afternoon 'cause bears/alligators/wild life may jump an attack me". It's pure excuse to NOT do things.
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.