Strong typing would not be an unwelcome addition to the Erlang space but compared to most dynamically typed languages I find Erlang/Elixer to be infinitely more usable. If you aren't using guards and specific type pattern matching you arguably are doing it wrong. And those things give you much of the type info you need while developing. No compile time help but it's a lot better than most other dynamic languages. I've built very large projects in Erlang and didn't find typing a real issue.
Because there are no fundamental tradeoffs between the strategies. Because if it was so objectively more efficient and effective every project wouldn't move to that strategy.
So is a distrubuted, trustless system allowing transferring information securely. It shouldn't take much to see how this is solution is valuable to certain problems.
> If it runs out of space, it creates that same path on another drive.
That's not how it works.
The policy picks what branch to use and then once selected mergerfs will clone the relative path as needed. With "ep" policies it will never select a branch that doesn't have the full relative path. "msp" will always rerun the check one level up in the hierarchy if nothing is found at the current level.
There isn't a lot of options when it comes to the basic interface to an API. You have functions and their arguments. They can be strongly typed like most random syscalls or generic like ioctl or some microkernels. io_uring's API is not so nice in the sense it is very generic on the surface and typing is handled in the data structure rather than signature so it needs wrapping for any language level typing support. And that that point, besides some internal details, what separates ioctl from io_uring? Could I not send similar data to ioctl and have it act similarly? At the end of the day it is just a way to shuffle data to and from the kernel. How the kernel acts on that is what matters.