Rust Support In The Linux Kernel Undergoing Another Round Of Discussions

[ssokolow]

That's a very weak argument. ifdef is a hack, cfg is much better, same goes for the macros and pretty much any aspect of the languages when compared. There's nothing preventing someone adding vim support to cfg flags.

True. I just use NERD Commenter in my Vim. Select the text with whatever motion you're partial to and type <leader>cb to comment the selected text or <leader>cu to uncomment the selected text.

[Luke_Wolf]

Granted it was over a year ago that I ported some code of mine from C to Rust in order to get a feel for the language, but yes the difference in compilation time was very noticeable then. Even this very RFC we are discussing brings it up as a negative:

So it sounds like it's very much still an issue.

Slower != Slow, and especially Slower != Very Slow. Pure C happens to be on the faster end of things as far as compile times go, but Rust is comparable to most other compiled languages that people actually use (C++, C#, Java, etc). Most of the complaints and the meme of "rust being slow to compile" is coming from Python and Go folks, who will never be satisfied. Again though if you're abusing macros now you can start having issues, but that's like abusing templates in C++ and then complaining about compile times.

[Grinch]

Pure C happens to be on the faster end of things as far as compile times go

Guess what the Linux kernel is written in.

[zcansi]

Slower != Slow, and especially Slower != Very Slow. Pure C happens to be on the faster end of things as far as compile times go, but Rust is comparable to most other compiled languages that people actually use (C++, C#, Java, etc). Most of the complaints and the meme of "rust being slow to compile" is coming from Python and Go folks, who will never be satisfied. Again though if you're abusing macros now you can start having issues, but that's like abusing templates in C++ and then complaining about compile times.

Also worth mentioning Rust pays a lot of attention to compile speed, it's tracked via CI at https://perf.rust-lang.org/dashboard.html and there is a team monitoring for unexpected performance regressions and improvements.

As you can see it's pretty steady improvement over time and cumulatively quite significant. There's actually another 10% improvement close to landing as well.

[Luke_Wolf]

Guess what the Linux kernel is written in.

Alright let me ask you this: would you compile your kernel with a compiler that's 50% faster for an executable that runs half as fast or would you use a compiler that's more complicated and thus takes longer, producing optimized code? Surely everyone here would take the latter.

What about same proposal but instead you can choose either a compiler that's 50% faster, and produces executables that run the same speed as the other, but the other one can remove 65-90% of all security bugs in the final executable?

Now let's make this more real world, let's hold the kernel at 30 million lines and say it takes 30 minutes to build on an arbitrary system now lets make the rust code 3 million lines and to make it favorable to you let's say it takes twice as long to compile rust as it does C, you added a whole 6 minutes to the build. Certainly nothing to cry over on a compile that takes a half hour anyway.

This is what you're complaining about.

Now if this was Scala where sbt takes a good 5 minutes on its own to start up before you can even run your compile command I might be more understanding, but that's not what we're talking about here.

[lyamc]

It is, and you didn't, because my question didn't imply anything. You wouldn't know logic if it bit you in the ass.

lol

[angrypie]

lol

Michael, do you allow underage users?

[lyamc]

Michael, do you allow underage users?

You should already know the answer to that, seeing that you’ve got yourself an account

[JustRob]

As a C programmer I resist the idea of adding Rust, when I can literally predict the resulting assembly language of my C program; due to my safe programming practices, and avoidance of ill formed code.

But when I try to argue against Rust I find things such as Oso Polar which bolster its inclusion; still I resist.

[Grinch]

Alright let me ask you this: would you compile your kernel with a compiler that's 50% faster for an executable that runs half as fast or would you use a compiler that's more complicated and thus takes longer, producing optimized code?

That has no bearing on this discussion, the difference in speed of generated code between C and Rust should be practically non-existant.

What about same proposal but instead you can choose either a compiler that's 50% faster, and produces executables that run the same speed as the other, but the other one can remove 65-90% of all security bugs in the final executable?

That very much depends how much of a problem you have with said bugs. Of course we are not just talking about changing compiler here, we are talking about a whole new programming language.

Certainly nothing to cry over on a compile that takes a half hour anyway.

A huge amount of effort is spent on improving compile time, this is done because compile time is a large factor in development, and there is no such thing as 'fast enough'. A constantly developed kernel like Linux is compiled 'quite often', so of course a significantly slower compilaton will be a detriment. Your estimated 6 minutes per compile adds up, you're not compiling once per day.

I'm not saying Rust being slower in compilation is a deal-breaker, if it was then this discussion would be over as a Rust compiler will be slower than a C compiler, given that it does more work due to more complex abstractions. It IS however a factor on the negative side, which the Rust proponents who wrote this RFC themselves acknowledge.