Comments by "Anony Mousse" (@anon_y_mousse) on "Rust Coming Soon To A Linux Kernel Near You!!" video.

Not that any Rustaceans will take valid criticism, but I hope one day that Rust disappears as a language. We need far less toy languages. Especially when it can't deliver on its promises. In kernel space they won't be able to have the erroneously labelled memory safety that they employ in user space. I personally wouldn't want any code contributed to any of my projects by people that need that "safety". As a point of interest, those aren't the only errors that programmers make, and there are whole classes of them that Rust won't "protect" programmers from. If anyone disagrees with this, I invite you to reply with your hopefully valid criticism. Or you know, prove me right about Rustaceans, either way.
1
@dynfoxx A basic allocator, yes, but not a garbage collector, not in kernel space. They make promises of safety as though every error will magically disappear, but that breeds apathy and carelessness which leads to bad programmers. There are still whole classes of errors that they can't protect anyone from and people should be wary of them all. For a single example as this is the comment section: consider how temporary files are used. If this leads to less experienced developers contributing to the kernel and they don't properly handle files, this could lead to leaking memory, leaking information which reduces or eliminates security and/or privacy, and of course data loss in case they delete a file they shouldn't. That single example should be enough to worry everyone, but it seems like no one is.
1
@dynfoxx It may not be GC on the level of Java, but it is GC. It's more or less a clone of C++'s most common style of GC. From a technical standpoint, it could be included in a kernel, but doing so will add the kind of overhead that shouldn't be in a kernel. Although it sounds like you disagree with that assessment. I don't see how you can conclude that they provide safe concurrency either. With barely over a decade of testing I'd need to see a fairly conclusive set of tests to prove that. As for the example, it wasn't meant as an example of known problems that Rust programmers have, although they very likely will, but rather as an example of how there are so many types of errors that they either don't or can't protect against and shouldn't be lulling newbies into a false sense of security by claiming they solve any class of errors. On top of that, in a kernel you need guarantees of speed. If you keep bounds checking turned on then your code will run significantly slower in quite a few circumstances than code which isn't bounds checked. If you turn the feature off, you're no better than C. You can claim that features like lifetimes and ownership will make it better, but the implementation requires extra code there that also slows things down. The runtime of a kernel shouldn't be holding your hand if you develop for the kernel, you should be at least a good programmer to do such work if not a great one. Of course, a lot of my opinion on this matter stems from the fact that I've worked with a lot of newbie programmers and I understand their psychology somewhat, and if you give a mouse a rope and tell them to hoist themself to the rafters, they'll very likely do so by their neck.
1
@dynfoxx It's not the same as calling free() in C. It's more like the methodology of C++, and yes, it is indeed extra overhead. If you implement your code in a library and interface it with other code, regardless of language, you can't have runtime checks of their correctness. There will also be certain checks for correctness that you can't perform in such a scenario even if you stipulate every expectation for code that calls yours, and yes even if the "client" in this scenario is also written in Rust. The biggest reason for my complaints about Rust in this regard is how similar it functions to C++, except that the language designers have chosen all the methodology for how things will work, and lead everyone they can into believing the language is safe. For you to claim that you can merely bypass their decisions for how you should do things by declaring your code unsafe is absolutely wrong. Essentially, what you're saying is, use a pointless keyword that gives those who don't use it a false sense of security and just write it in C with a weird syntax. You keep talking about C++ features in Rust but you're using exclusively the Rust names as though I have no idea how one or the other or both work and then you're claiming it doesn't work the way you and I both know it does. Have you ever used C++? Do you know of all the features it includes? Even just up to 11? If you're as staunch a Rustacean as you seem, I wouldn't expect you to keep up with 17, and certainly not the latest standard, but at least 11 which was the last standard before Rust was released.
1
@dynfoxx You still aren't understanding my argument here, but let's quibble over the details instead. Drop does more than you think, take a look at the assembly output sometime. That's a lot of overhead. I'm not even limiting this to FFI, even calling pre-compiled Rust from some other library is a potential problem. Part of my disagreement with unsafe code in Rust is the explicit labelling of that code as unsafe. There is no safe code in any programming language until it has been properly debugged and merely not crashing is not good enough, especially in kernel space. Whether you can bypass bounds checking wasn't the issue, because of course you can, but that's not the only way memory is accessed. I'm not sure why you brought up version 1.0 when I wasn't stipulating any particular version, just when it was first released, and the first version available was 0.1, which was released in 2012. That's not to say the creators of the language weren't toying with it earlier. After all, some people develop their own languages and toy with them for over a decade before making a public release.
1
@dynfoxx If it inlines it, which isn't a guarantee. If you were writing it in C, sure, it would be up to the programmer to get it right, but if they do, and multiple decades old code will be right due to debugging work, then it'll work more efficiently without the need for quasi-guarantees as it will already have been guaranteed for years. How are logical issues merely an API issue? Any programmer can get those wrong at any level, no need to be an API implementer nor need it be down to how the API is used, both could be at fault as well, at the same time. Also, you and the Rust developers can't guarantee that bugs will be found and fixed in a timely manner any more than kernel developers already can, and bugs found in C code do actually get fixed. Obviously the guarantees that the kernel already provides should be good enough, but introducing a new language requires checking everything all over again. I wouldn't want C++ being introduced any more than Rust or any other language of such complexity, and they did try C++ for a time and rejected it as I'm hoping they will for Rust. However, what the future holds on that we both definitely disagree. As for an MTC on Godbolt, that'll have to wait until I'm finished moving. Something that I'm sure doesn't normally take this long, but it's exhausting when you can't take time off to do personal things.
1
@dynfoxx The point about bugs in C was that most of the C code is so old that it has already been debugged, whereas if any Rust code is added it'll require that process start anew. As for guarantees, like I said, everything it already provides, whether that's dependent on any given language or not, as long as it keeps on truckin' as good as it always has. I've not run any tests as I don't use Windows, but I'd wager it is faster and more memory efficient than the Windows kernel. If Rust in the kernel works as well as the C code, I would definitely reevaluate my position on it, but I'd also have to audit such source myself before I'd trust it. My main objection to it is not just that it isn't and can't possibly be as safe as they claim, but that it gives far too many newbies too much confidence that they can write kernel modules and there are far too many programmers that I wouldn't trust to write a clone of notepad let alone a kernel module. Hopefully you can at least understand that particular point of view, maybe even agree with it somewhat?
1
@dynfoxx I definitely see bad programmers as the problem, but the language can make them complacent. If they think it'll work miracles for them, they won't work as hard to write correct code. It's a psychological problem with humans. They must be pushed hard to get good results. I think a possible compromise might be to force all code written in Rust for the kernel to be labelled unsafe. That would force them to pay more attention. I'm sure you'll disagree, though, and if so, I'd be curious what reason you cite.
1
@dynfoxx If the tools catch the error, then you'll know where to look, but if they don't you'll think you know, and look at the "unsafe" bits and be very confused if those are the only parts that are correct. With C, not C++, since the entire program is deemed, by some but not all, to be unsafe, then you'll only know where to look by figuring out what it's doing wrong. If you apply such knowledge in a general manner, it would benefit you more as a Rust developer. Don't depend on the tools to do your job for you, in other words. Hopefully you'll influence others to be good or great programmers, even if they are using Rust.
1
@dynfoxx It's really weird for you to say you have better tools when all of those things are available for C. Not by the name miri, of course, but there are debuggers that work better than GDB and can be used for C. As far as I've seen, most C programmers write test cases, and more than a few write documentation. Granted not all, but Rust doesn't require those things to build your code, and there are tools that allow you to write them easily for C programs too.
1
@dynfoxx That would depend on how it's implemented. In general, C++ has a lot of overhead in this regard, and it's pretty hard to avoid it. As in the syntax they've chosen makes it a PITA for the programmer to deal with it. In C you implement everything manually so there is no overhead for anything, you do it, or you don't do it. I would be interested in learning more about how Rust handles that, if you could point me in the right section of the source code?
1
@dynfoxx Like to handle either allocations or frees it inserts a function call, something you would do on your own anyway, unless it doesn't inline it then it has to make multiple calls, possibly through a trampoline, which can be pointlessly bloaty. I can read enough of Rust to parse the source easily enough, it's easier than reading some people's C++, though I personally write really clean C++, not that I enjoy doing so.
1