Comments by "TheEVEInspiration" (@TheEVEInspiration) on "what is wrong with rust and linux????" video.

  1. When going over process boundaries, this shift in responsibility/handing over ownership should not even be a thing. If I use a binary/application I should not have to care what it is written in and what the associated internals demand of me. Having file system XYZ written in Rust should be identical in API expectations as the same file system XYZ written in C. The API and any poorly thought out semantics should be identical. There either is a good API or a poor one!
    1
  2. As for documentation, code does NOT equal documentation. Fact is that code can be technically correct and compile, but at the same time still provide an unintended/poor interface with even a worse implementation. How will it ever be tested by others, if the poor implementation translates to the binary standard going forward? It lacks a proper test/correction mechanism! So with respect to binaries providing a service, its a sin not to document the actual intention. With this I mean what can or cannot be expected from the implementation and its usage context with examples. How else is there any validation of the API possible? The compiler will not call us when the API does not match intentions, but a different programmer will! And by writing the documentation, logic flaws typically surface as any hard to explain things usually points to the code/API not being right.
    1
  3. First An OS must be language neutral and provide just a service to the outside and facilitate clear communication via APIs and services around process management/recovery. Second There must be clear boundaries between binaries, each possibly written in a different language. The APIs connecting them should adhere to the most basic information exchanges and not carry over "object" responsibilities between binaries. I get the feeling neither of these two rules has been followed or people are now trying to break these basic rules. 1. The rust bro's try to put semantics where they do not belong via their language. 2. The C bro's might already have convoluted APIs where the unenforceable responsibilities shift over binary boundaries, without going crazy on types. So maybe both are wrong. Developers just expect/need clarity who owns a piece of data and that the responsibility over that data to be with the binary that defines/instantiates that data. This is why file systems work with simple integer handles and do not share the actual data structure behind it with the outside! Ideally, if a structure holding information needs to be communicated to the application, the integer handle should be used to produce a read-only copy of requested data and not an internal object. The API must form a clear isolation from the internals of other binaries. I will even argue that the application should provide the memory for the output from its own pool, as well as how much it allocated. This way the service behind the API can grow its structures if need be. If there are any checks that a API client needs to do, like checking for NULL and/or some standard first element member check, it should apply to all API calls on not just specific ones! If more complex rules than this apply around the given out data, this should by standardized by the facilitating OS Kernel. In a way that allows the producing binary, say a file system binary, to do proper cleanup when an application crashes. If current binaries and/or Linux kernel work different, then in my book, its a mess. Can't have an application be responsible for the internal state of a file-system after all.
    1