Google Wants To See Rust Code In The Linux Kernel, Contracts The Main Developer

[NobodyXu]

116 messages from people absolute most of whom have never submitted a single line of code to the kernel and most of whom have never written a single line of code. LMAO.

I won't even attempt to read any comments in this "discussion". Rust or not in the Linux kernel - that's of very little essence. What matters is stable API/ABI and Rust won't solve it.

First thing first , linux kernel has made the decision long ago that there will never be any truly stable API of the kernel, which means that if you maintain out of tree patch, you’ll have to modify from time to time to make sure the code won’t break.

Here’s the link to the LKML https://www.kernel.org/doc/Documenta...i-nonsense.rst

So it doesn’t matter that rust doesn’t have stable API, since linux kernel never really cared about stable API.

In fact, linux kernel want the API to be unstable so that they can introduce whatever changes they want without considering backwards compatibility at all.

The only stable API/ABI are the syscall, but even rust support that by allowing types and functions to be defined to be compatible to C, though this is currently not required as rust will only be used for module right now and not gonna rewrite the whole thing in rust in one night.

[NobodyXu]

If Rust is to be used, I would say, why not, but not for time-critical processes.
The gcc or clang compilers, over the years, have become enhanced highly optimizing. The compilers review the code and is able to perform optimizations better than many humans.

The Rust compiler does not appear to have the attention to optimization that has been built into gcc or clang over the past 10+ years.

Rust is built upon llvm.

rustc is just a compiler frontend, similar to clang, that compiles rust into the llvm bitcode.

It will then be optimized by llvm.

The same thing goes for clang which compiles C/C++ to llvm bitcode and let it do the optimization.

[moltonel]

116 messages from people absolute most of whom have never submitted a single line of code to the kernel and most of whom have never written a single line of code. LMAO. I won't even attempt to read any comments in this "discussion".

So you've decided, without reading any of it, that the discussion was worthless, but that you could still contribute to it ? There are lots of Linux/Rust skill levels in this thread, you would hopefully feel some humility if you read it.

Rust or not in the Linux kernel - that's of very little essence. What matters is stable API/ABI and Rust won't solve it.

QED: Rust ABI stability in the kernel is a non-issue. The internals don't care, and the userspace API uses C-style symbols, which Rust has no trouble using or exposing.

[moltonel]

The Rust compiler does not appear to have the attention to optimization that has been built into gcc or clang over the past 10+ years.

That is plainly false. Rust benefits from the same optimization pipeline as Clang does, and will have the option of using the gcc pipeline when rustc_codegen_gcc is ready. A lot of work is spent on the frontend to make sure the backend can do its magic and to hold Rust's zero-cost abstraction promise. The Rust language gives more information to the compiler than C or C++, enabling things like noalias optimizations or better bounds check eliminations. All in all, Rust performance is on par with C and C++.

[andreano]

…

How ironic, how untrue,
the least constructive post has come from you.

[ssokolow]

All in all, Rust performance is on par with C and C++.

In benchmarks. (Note that, if you watch that over the course of several months, you'll see C, C++, and Rust trading places. There's a lot of noise in that signal thanks to C, C++, and Rust adherents fighting to find more ways to be the most optimized.)

In real-world use-cases, where maintainability is a concern, various people, such as Bryan Cantrill, have reported Rust being faster.

(In that YouTube video that I linked into the middle of, he basically says his naive Rust implementation outperformed his skilled, optimized C implementation and, when he explored why, he found that it was because Rust came with a highly optimized B-Tree implementation (std::collections::BTreeMap and the BTreeSet<T> which is basically BTreeMap<T, ()> fed through the optimizers), while, even knowing the performance he was giving up, he didn't want to maintain and debug potential memory corruption issues in anything gnarlier than an AVL tree in C.)

I don't know if that's the same code he was talking about in this post (Falling in love with Rust - The Observation Deck) when he wrote:

Yes, you read that correctly: my naive Rust was ~32% faster than my carefully implemented C. This blew me away, and in the time since, I have spent some time on a real lab machine running SmartOS (where I have reproduced these results and been able to study them a bit). My findings are going to have to wait for another blog entry, but suffice it to say that despite executing a shockingly similar number of instructions, the Rust implementation has a different load/store mix (it is much more store-heavy than C) — and is much better behaved with respect to the cache. Given the degree that Rust passes by value, this makes some sense, but much more study is merited.

It’s also worth mentioning that there are some easy wins that will make the Rust implementation even faster: after I had publicized the fact that I had a Rust implementation of statemaps working, I was delighted when David Tolnay, one of the authors of Serde, took the time to make some excellent suggestions for improvement. For a newcomer like me, it’s a great feeling to have someone with such deep expertise as David’s take an interest in helping me make my software perform even better — and it is revealing as to the core values of the community.

Continuing on that theme of "language features make programming to the same standard more comfortable and make programming to a higher standard less off-putting", he also wrote a more recent post named Rust after the honeymoon.

[timrichardson]

A little strange Google wants to support a Mozilla language, when they have Go.

EDIT:
I'm not saying Google should be using Go...

Have heard of JavaScript?

[schmidtbag]

Have heard of JavaScript?

Yes? What of it?

[smitty3268]

Yes? What of it?

It had a similar origin at Mozilla, and Google uses it fairly prominently.