Rust Support In The Linux Kernel Undergoing Another Round Of Discussions

[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.

[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.

[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.

[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.

[Grinch]

Rust isn't actually slow to compile at all

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:

Slower compilation in general, due to more complex language features and limitations in the current compiler.

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

[cynical]

There's been a lot of discussion about them in the RFCs. One of the big problems is that those are both "easier said than done" features in a language that cares about competing with C and being a "make costs explicit" language.

I can already tell it's not going to happen. It's not a matter of cost imo, it's that once you implement such a thing, you'll want a nicer API (just look at the variations of split/trim methods for string) and that would mean the older methods would be deprecated (which truthfully would be horrible). That ship has sailed imo.

We're all wired to look for familiar things (useful as they may be), but that is a red herring when assessing a new language. No language implements every feature ever thought of, the true measure of success is whether you can be productive with whatever features it does happen to implement (and yes, that totally means that I may be ok with a language you hate).

My go to example for the above is Go: few OOP traits, garbage collected, limited enum support, no pattern matching in switch expressions, no generics (soon-ish to change). Yet if you give it a try, you can be very, very productive with the features it does have. And that includes its runtime and tools.

Absolutely true, but note what you said about generics. Some things are just plain nice to have, even if you could do without them. I think Rust is fine as is (which is quite nice), it's just not as elegant as it could be. I'm coming from the perspective of a high-level language user though. Rust is a massive improvement over C or C++ for me so it's a win in the end.

[programmerjake]

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.

iirc vscode has support for greying-out cfg-disabled code when used with rust-analyzer, I'd expect vim might have similar support since I think it's rust-analyzer doing all the work and vscode just using the language server protocol support, which vim also has.

[angrypie]

lol, that’s not what slippery slope means, and I used the same logic that you did

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.

[Almindor]

The tricky part is the editor integration.
Vim can recognize #if 0 #endif, but afaik there is no standard pattern for cfg (no, "if cfg!(false)" doesn't work)

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.

[lyamc]

"Is arguing so hard lyamc had to resort to slippery slope to say anything at all?"

lol, that’s not what slippery slope means, and I used the same logic that you did