Comments by "" (@diadetediotedio6918) on "Torvalds Speaks: Rust's Impact on the Linux Kernel" video.
-
6
-
5
-
4
-
@rt1517
First off, the linux kernel is big, and nobody is talking about rewriting <the whole thing> in Rust, it is an adaptative and incremental process (which is already being carried on on other operational systems like Android, which 21+% of the new code is Rust). Secondly, the compilation in Rust is known to be slower on the first times, but generally fast on the other times, and it can be improved by splitting the project into multiple modules (which is an actually used resource, and it just works, most of the projects don't take more than 1s to compile after they are compiled the first time when properly split in modules), so this is not an immense and unsolvable problem (and of course, the Rust team is also working to improve on compile times). That's sorted out, right?
Fine, then:
RAII is used in the official Rust documentation as an analogous of the C++ functioning, it is true and I acknowledge it that Rust do uses a kind of RAII in it's workings, but it has some differences from the C++ way of doing it, and while it is okay to refer to the Rust model OBRM as "RAII", these differences appear significant to me in the way they integrate with the compiler and the previsibility of how things will go (related to the borrowing and ownership systems). But that's fine, and still, it is obvious from the context, you didn't provided any reasoning on why it is not when it is clearly defined and very intuitive from the beginnings: If you go out of scope, whatever that scope is, the resource is dropped. The ownership/borrowing system makes it obvious that it <will> be called whenever the resource is owned, and the syntax is pretty clear about who owns who, in this sense everything can be easily deduced. You can counterargue with that, but this appears to be not a extremely controversial thing.
Next, the struct "may not implement the Drop trait", but this is not a general problem of the language, because fundamentally <you don't need to implement it manually>, the Drop trait is inferred as a basic concept in the language and it is implicitly implemented in these cases (which imply that the memory will be dropout, as intended, explicit Drop implementations are far more specific and goal-directed, so this is a no-problem).
Of course I understand your point that "a function is called and we cannot see it", but this is a more opinionated take than anything, and as you realized Linus don't care about this because of the benefits of the language over the drawbacks (if you can call this a drawback on itself, as I said, the Drop's are mostly obvious from the scope). The Linux kernel has a lot of macros and nasty stuffs as well, including some 'implicit' things if I remember correctly seeing them in the commit logs and some articles, so I don't think most of people that develop kernels care about this so much to make this a real problem.
For the last part, I don't see who are you to judge what is a "good C code review", maybe you are a 30+ yeard old programmer like Torwvalds himself and see things most other people don't see, but I'm not seeing him complaining about this like you are. As for the parts you are refering to, they have a rational motive behind:
```
// Note that errors are ignored when closing a file descriptor. The
// reason for this is that if an error occurs we don't actually know if
// the file descriptor was closed or not, and if we retried (for
// something like EINTR), we might close another valid file descriptor
// opened after we closed ours.
```
As they explain, this is a thing that cannot be avoided in this context, this does not means that in the kernel code they will use this implementation and not a custom one (and they are making a bunch of them as well, if I remember correctly they are making a whole utility box for this), for most of the user-level code this function not checking if the file descriptor was closed does not effectively matter, it is a safety measure over what cannot be known in this specific context, it is an understandable and documented choice and, if you can solve it, you can improve the Rust codebase by sending a pull request on it instead of just complaining without solutions.
2
-
@rt1517
1. Nop, the comment is explicitly saying that we can't know if the file descriptor was closed or not, and if we try to retry it again or handle the error (and they cited EINTR as an example) that they might close other valid file descriptor opened after they closed theirs. It is not saying this is only the case for EINTR. As I said, if you care you should probably close it manually and verify instead of relying on implicit behavior in this case, this is not a problem of the language itself but a worry on the developer (as it should be with these more explicit things, as we have with sync_all), a no problem on itself.
["And the issue is known and discussed by the Rust community, for years. Yet no good solution has been found."]
As for this, you should probably suggest it then, as you are saying this is a mistake and that the linux already solved this problem, what about it?
2. ["There is a kernel in C#.
Does it means that C# is good enough to be introduced to the Linux source code too?
I wrote a Windows driver in Delphi in 2010. It worked. Maybe Delphi should be introduced to the Windows kernel?"]
You are being fallacious here, this is not nice bro. I'm saying modern companies are investing on Rust for kernel/driver/OS development, I'm not saying some hobbyist is doing these things or using it as a mean of auto-validation of the language, instead, I'm saying that the language <is being appropriated> according to the kernel/driver/OS developers. But your question is pertinent if C# was actually an appropriate language for kernel/driver/OS development, which it is not. If C# did not had problems with memory management, performance and/or was made for the purpose of systems development (like Rust was), then surely C# or maybe even 'Delphi' would be suitable for the job. You appear to be dismissing C# because you think it is not suitable, which begs the question, C# is not suitable because of N factors, while Rust is suitable because of N factors and the fact that there are successful implementations of it in important systems is an indicative <more> of it's appropriatedness besides the theoric stuff (and obviously, I'm not saying Rust is appropriate based solely on the fact that it was used).
3. ["Linus is well known to be an arrogant thick headed guy.
He wrote Git after not finding a good source-control management system."]
Yes, and now git is one of the most used source control management systems in the whole world of software development, maybe he's right after all, no? Again, I don't think you have the property to question his decisions or say "he became weak with age" if you don't have something as big as what he did and contributed to show here, this is bs.
2
-
2
-
2
-
@rt1517
1. It is related to the comment in the Rust code bro, what are you saying? It is pretty clear why they made this decision in this context, and they stated it explicitly. And as I agree with you that this <can> be <potentially> a problem in <some> situations, I don't think it is a hard and strict rule of how things should work. As I said, they commented on why they can't verify and return these errors, they reasoned about it, but even so you should not blame the feature as a "design flaw" just because of it, in the same way we don't blame any language that has automatic resource management (including defer) as a flaw because they can't avoid some pitfalls (like C# automatically disposable structs lacking a owning mechanism or verification one), a programmer should them take care in cases this is important and verify manually. In the end, it does not matter at all if you don't care about the result, which is the case in most userspace programs, as I said before.
2. ["C has a lot of issues and a new language should be introduced in the kernel.
But Rust, while it solves or tampers some of C issues, introduces some other issues.
Linus seems to have not spent the time to learn Rust enough to anticipate these issues."]
First of all, yes, Rust has it's own issues (as all languages have, there's not a silver bullet in programming and things don't come freely), but you are underestimating Linus and overcritizing Rust by some things that frankly are just bs most of the time and that are being constructed around in many ways, so the question is not it "introduces some other issues" or not, but wheter it have value to add (which the language has in many ways, including new developers openness and important native safety features C lacks). You can say Linus "didn't take the time to learn", or you can recognize that he is a skilled developer with good contacts and that is actively reading Rust code to be merged (as he itself said in the video), and that this is constraining the directions of the language in the matter. And as a matter of fact, we can say that Rust is <appropriated> for kernel code because we know Asahi graphics drivers were writen on Rust and they are working pretty well (and the main developer said it was objectively easier and more reliable to make than with C), we know that Rust is being written on Android OS code and it is giving Google less problems than before (read the report), and we also know that Rust was indeed used for developing entire kernels before (so it works on this matter specifically as well), so I don't think you are the big reference here on critizing the appropriate usage of the language or to say they needed to "create a new language for their use case, kernel development", this bears arrogance.
1