
Linux kernel in-tree Rust support - littlestymaar
https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/#u
======
roca
Rust in Linux will be fantastic _except_ for compile time. Rust (and the
world) needs a Manhattan Project to build a fast Rust compiler (where by
"fast" I mean both efficient and scalably parallel when compiling a workspace
with many crates and long dependency chains).

To put this in perspective, though: increasing the number of people paid to
work on the Rust compiler by 10x would only mean hiring about 25 people.
Compared to the size of the projects that are starting to depend on Rust,
that's a rounding error.

~~~
crazypython
GCC 10 supports Dlang directly. (The support is still immature and it's being
updated to the newer version of Dlang.)

Dlang compiles quickly not because the language is simple, but because the
compiler authors care about compilation speed:

Lexer skips four spaces at once
[https://github.com/dlang/dmd/pull/11095](https://github.com/dlang/dmd/pull/11095)

Optimize core logic to 7x compilation speed of language feature
[https://github.com/dlang/dmd/pull/11303](https://github.com/dlang/dmd/pull/11303)

Cache rarely used types to improve memory locality
[https://github.com/dlang/dmd/pull/11363](https://github.com/dlang/dmd/pull/11363)

~~~
geofft
The D language uses GC, so it's unlikely to be acceptable for the Linux
kernel. (That's not to say that you can't write a kernel in D, just that the
Linux kernel maintainers don't want to write a kernel that requires GC.)

Rust's ownership model, which allows you to write straightforward, non-leaky,
non-use-after-free-filled code without a GC, is quite complex at compile time.
It's definitely possible to make it faster, but it's definitely a thing Rust
does that D doesn't do.

~~~
CountHackulus
D has a nogc flag that can be used on methods and taints methods down the
line. It's pretty neat. I'm a big fan of D, but I still think I wouldn't write
a Kernel in D. I find it much more suited to quicker smaller programs, kind of
like Python but with better typing. The script support for D is also really
neat, and I've used that instead of Perl a few times.

------
ComputerGuru
These threads always devolve into "rust is too slow" written by developers (or
enthusiasts) that have never written no_std code in production. I've written
and shipped firmware for embedded devices written in rust, yes, still using
cargo and external crates, and had zero issues with compile time because the
nature of the dependencies in the deps tree is different and very carefully
curated.

Anyway, I really just wanted to point out that from the mailing list we have
Linus and Greg endorsing this experiment/effort from the Linux side and a
commitment from Josh on behalf of the rust team to grow the language itself
with the needs of the kernel in mind. That's quite impressive and more than I
could have hoped for.

I've actually played with writing kernel code in rust - for Windows/NT,
however - and it's quite weird to be able to use such high-level type
constructs in code where you typically manually chases pointers and wouldn't
be surprised to see statically allocated global variables used to monitor
reference counts.

~~~
ksec
Linus, normally being C has its quirks but is great and Anti C++ in general is
endorsing Rust?

Why is that? Did he ever gave out his reasons?

~~~
geofft
I don't know Linus's reasons specifically, but our presentation at Linux
Security Summit last year laid out why we think that Linus's past objections
to C++ don't apply to Rust. See slides 19-21 of
[https://ldpreload.com/p/kernel-modules-in-rust-
lssna2019.pdf](https://ldpreload.com/p/kernel-modules-in-rust-lssna2019.pdf) .

His previous objections were:

    
    
        In fact, in Linux we did try C++ once already, back in 1992.
    
        It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
    
        The fact is, C++ compilers are not trustworthy. They were even worse in 
        1992, but some fundamental facts haven't changed:
    
         - the whole C++ exception handling thing is fundamentally broken. It's 
           _especially_ broken for kernels.
         - any compiler or language that likes to hide things like memory
           allocations behind your back just isn't a good choice for a kernel.
         - you can write object-oriented code (useful for filesystems etc) in C, 
           _without_ the crap that is C++.
    

In brief, Rust does not rely on C++-style exception handling/unwinding, it
does not do memory allocations behind your back, and its OO model is closer to
the existing kernel OO implementation in C than it is to C++'s model. (There
are other good safe languages besides Rust that I personally like in _general_
but do not satisfy these constraints for this particular use case.)

~~~
andai
How do you write OO code in C?

~~~
amw-zero
This is a really in depth read about OO design patterns in the Linux Kernel
using C: [https://lwn.net/Articles/444910/](https://lwn.net/Articles/444910/)

The easiest to understand example (for me) is that you can manually implement
polymorphism support using function pointers that take in a struct instance as
an argument. Polymorphism is fundamentally just a method call that's dependent
on which target object it's being called on, so this pattern allows you to
pass in the target object (as a struct since it's C) explicitly.

From the article:

> Some simple examples of this in the Linux kernel are the
> file_lock_operations structure which contains two function pointers each of
> which take a pointer to a struct file_lock, and the seq_operations vtable
> which contains four function pointers which each operate on a struct
> seq_file.

~~~
jeffbee
The huge and important difference is when you use this pattern in C the
compiler has no idea what you are doing and can't check anything, nor can it
reduce the cost of this dispatch mechanism. A compiler for a language where
this is a feature can check what you are doing and de-virtualize virtual
dispatch. In C you pay the highest possible cost for polymorphism while
enjoying the least benefits.

~~~
Jasper_
> The huge and important difference is when you use this pattern in C the
> compiler has no idea what you are doing and can't check anything

Function pointers exist in C and are type-checked by the compiler just fine.

> A compiler for a language where this is a feature can check what you are
> doing and de-virtualize virtual dispatch.

Virtual dispatch is pretty much only used in the kernel in places where
virtualization is necessary. Devirtualization is pretty rare in C++ in
practice (I don't believe I've ever seen a "virtual final" method, and my day
job is on a large C/C++ codebase).

~~~
saagarjha
You don't need "virtual final" for devirtualization, the compiler will
speculatively devirtualize in some cases.

------
rwmj
The title is not very accurate, this is a thread about a discussion on this
topic which will happen at the upcoming Linux Plumbers Conference in late
August.

~~~
chrismorgan
The title is perfectly accurate, it’s an email thread about Linux kernel in-
tree Rust support. Sure, you could misconstrue such a title to be implying
that the Linux kernel supports Rust in-tree already it if you wanted to, but
half the titles on a site like this could be similarly misconstrued.

~~~
jaekash
> The title is perfectly accurate, it’s an email thread about Linux kernel in-
> tree Rust support.

The title the person you are responding to is complaining about is not the
title of a email thread but the title of a hacker news post.

~~~
chrismorgan
Unless there’s a strong reason not to, the Hacker News post title should match
the email thread title. It does match, and I see no even _slightly_ compelling
reason for it to deviate.

------
xvilka
Immunant folks wrote a blog post [1] about automating conversion of Linux
kernel drivers from C to Rust by using their tool c2rust[2].

[1]
[https://immunant.com/blog/2020/06/kernel_modules/](https://immunant.com/blog/2020/06/kernel_modules/)

[2] [https://github.com/immunant/c2rust](https://github.com/immunant/c2rust)

~~~
yjftsjthsd-h
I don't see them discussing what I view as the biggest question of such
conversion: is the converted code safer than C, or is it a direct translation
with all the issues that we were trying to fix by using Rust? (This came up,
IIRC, with automatic C to Go; it _worked_ , but was only useful as a first
step because it gave you unsafe unidiomatic Go code)

~~~
steveklabnik
It is currently a direct translation into unsafe.

They are also interested in "unsafe to safe refactoring tools" in my
understanding, but they're not there yet.

~~~
xvilka
There is a good refactoring tool[1][2] to automate the process. It also allows
scripting in Lua[3].

[1] [https://github.com/immunant/c2rust/tree/master/c2rust-
refact...](https://github.com/immunant/c2rust/tree/master/c2rust-refactor)

[2] [https://c2rust.com/manual/c2rust-
refactor/commands.html](https://c2rust.com/manual/c2rust-
refactor/commands.html)

[3] [https://c2rust.com/manual/c2rust-
refactor/doc/scripting_api....](https://c2rust.com/manual/c2rust-
refactor/doc/scripting_api.html)

~~~
steveklabnik
Oh awesome! Thank you!

------
pepijndevos
Pleasantly surprised by Linus response. IIRC his attitude to C++ was that it
should be refused if only to keep C++ programmers out.

~~~
for_xyz
His attitude towards C++ also changed when using it for his side project [1].

Initially he started with C and GTK+ and later migrated to C++ and QT
Framework.

[1] [https://subsurface-divelog.org/](https://subsurface-divelog.org/)

~~~
globular-toast
Did he have an "attitude" about C++ in general? I thought he only commented on
it with respect to operating system development. He did make much more general
statements about Java, though.

~~~
eru
I thought the famous comment on C++ was in the context of git, not operation
systems?

------
mijoharas
So this surprises me, obviously this is early discussion about a potential
topic, but the general consensus seemed to be more positive than I thought.

I thought I'd remembered reading something (maybe from linus) that seemed very
against having rust in the kernel, can anyone find a source for that, I
searched a little and can't?

(caveat, I obviously realise that linus isn't supporting rust in the kernel,
and is only saying something bounded that, if we have it, it shouldn't be
completely hidden behind some config options, but it doesn't match my memory)

~~~
gtirloni
Maybe you're remembering Theo's comments about Rust in OpenBSD?

[https://marc.info/?l=openbsd-
misc&m=151233345723889&w=2](https://marc.info/?l=openbsd-
misc&m=151233345723889&w=2)

~~~
raverbashing
The sad part is that Theo's answer on the thread seems to be one of the most
polite and realistic ones

~~~
ColanR
This was interesting to read:

> Such ecosystems [Rust] come with incredible costs. For instance, rust cannot
> even compile itself on i386 at present time because it exhausts the address
> space.

~~~
imhoguy
But is that a huge issue? One could compile on better machine with i386
target, no?

~~~
ColanR
According to the link above, in openbsd the policy is that 'base builds base'.
Rust can't be included in the base on i386 without violation of that policy.

~~~
estebank
And this is a reasonable and understandable policy. It just means that Rust in
it's current form is not a good fit for OpenBSD base system.

------
asveikau
Just stating something obvious since I don't see it noted here: Linus is a
smart guy with this idea of not wanting it to be some niche feature that
nobody enables and hence nobody cares about and sees breakage from.

~~~
merb
I think what he did has nothing to do with smart. it's experience that matters
here, he learned such stuff, sometimes even on the hard way.

~~~
asveikau
The smarts, I guess, is in recognizing which pieces need this treatment and
which do not.

Also, he is suggesting this change to experienced people who did not do it
that way. So experience is not 100%.

------
xondono
I always find these email threads very hard to follow, specially on mobile.

Is there anyway to have them shown more friendly?

~~~
canofbars
Firefox reader mode seems to do a decent job

~~~
manjalyc
It is also a blessing for paywalled news sites.

------
daenz
6 months ago, as I hopped on the Rust train, I told a friend of mine that I'm
convinced that Rust will "eat the world" like Python did[0]. These moves to
see Rust enter the Linux kernel only prove to me that this pace is starting to
pick up.

0\. [https://www.techrepublic.com/article/python-is-eating-the-
wo...](https://www.techrepublic.com/article/python-is-eating-the-world-how-
one-developers-side-project-became-the-hottest-programming-language-on-the-
planet/)

~~~
tptacek
This is a deeply weird comparison.

Insufferably lazy "eating the world" headline aside, Python is incredibly
popular because its runtime performance is "good enough" for a huge fraction
of applications, its safety guarantees are leagues better than C/C++, and it's
deliberately simple to write (it was designed in part as a pedagogical
language).

Rust's performance is leagues better than Python's, it's safety guarantees are
better by degrees, and it is _substantially_ harder to write than Python, not
just because it requires a more sophisticated understanding how how programs
are constructed and verified, but also because it requires developers to think
carefully about memory management.

I fully expect Rust to "eat the world" of C/C++ code over the next 10 years,
and look forward to a time where we'll look askance at kernel code still
written in C. It will no doubt be important in a bunch of performance-critical
settings (AAA gaming, browsers, network infrastructure) as well.

But Rust will never "eat the world" of general applications (that is, the
overwhelming majority of applications), because Python is good enough across
all axes for these applications. It would be engineering malpractice for most
companies to rewrite working Python applications in Rust. That was not the
case for C-to-Python (or even PHP-to-Python) rewrites.

In case this isn't obvious to anyone reading this thread --- though I'd be
surprised --- the reason Rust is in the Linux kernel, while Python isn't, is
that Rust was designed to be interoperable with kernels and browsers, and
Python, like most other languages that have ambitious runtimes, was not. It's
not an indication of Rust's popularity, but rather just Rust doing something
it was designed to do.

(Rust is plenty popular.)

~~~
fctorial
> Python is incredibly popular because its runtime performance is "good
> enough" for a huge fraction of applications

Is there anything slower than pure python?

~~~
devenblake
Interpreted BASIC, of which (in my opinion) Python is the spiritual successor.

I took an online class in college on Python and one of the assignments
required the program to scan a plaintext wordlist for a word. I hesitantly
made Python load in the entire wordlist and split it by newlines into values
in a list, before something like "if word in wordlist". I fully expected my
computer to grind to a halt because the _interpreted language_ was loading in
a four _megabyte_ textfile, and I expected to have to make a much more
complicated function to scan to see whether the word was in the list. I ran it
and it ran in less than a second before printing whatever I put to signal that
it worked. I didn't believe it so I ran it again with the same result.

Python is like BASIC if it was stable enough to be mission-critical and fast
enough to work where it needs to. My previous experience with interpreted
languages was with TI-BASIC and it blew my mind that my laptop was powerful
enough to do something that fast. Sure, it's slow, but if you really need
speed you're better off writing something in something like C or FORTRAN (or
Rust now) anyway.

------
rwmj
Assuming this happened and some essential drivers were written in Rust, would
this effectively exclude GCC from being used to compile the full kernel?

~~~
est31
GCC can still compile the components written in C. Only drivers for select
hardware might be written in Rust in the future, optional components
basically. And GCC won't be more disadvantaged than clang, as clang can't
compile Rust code either. The only production compiler that can compile Rust
is rustc.

~~~
rwmj
rustc uses LLVM like clang. That seems important because features like LTO
require the whole kernel to be compiled with the same toolchain.

~~~
est31
It seems to me there isn't mainline LTO support yet?

~~~
ndesaulniers
Work in progress. The series was resent two weeks so. We've been shipping it
in production in kernels in Android for years.

------
Jonnax
So I don't know much about kernel development.

How many other languages apart from C are there in the kernel?

~~~
correct_horse
I'm a bit uninformed as well. Obviously it must use assembly in some places,
it has makefiles for building and some scripts in perl. Here's what a cloc
clone has to say.

    
    
        tokei
        ===============================================================================
        Language            Files        Lines         Code     Comments       Blanks
        ===============================================================================
        ASN.1                  11          484          343           33          108
        Assembly                3         2751         2450            0          301
        GNU Style Assembly   1296       370153       270691        56418        43044
        Autoconf                6          347          303           20           24
        Automake                3           31           23            3            5
        BASH                   54         1991         1438          321          232
        C                   28971     19846129     14634535      2351170      2860424
        C Header            21110      6056898      4465297      1010398       581203
        C++                     8         2313         2016           68          229
        C++ Header              2          125           59           55           11
        CSS                     1          137           80           29           28
        Device Tree          3351       900862       735380        54238       111244
        Gherkin (Cucumber)      1          252          174           50           28
        Happy                   9         5750         5061            0          689
        HEX                     1           86           86            0            0
        INI                     1            7            3            3            1
        JSON                  328       174872       174872            0            0
        LD Script              15          412          317           48           47
        Makefile             2587        64666        43896        10957         9813
        Module-Definition       2          124          109            0           15
        Perl                   53        40583        31126         3931         5526
        Python                118        36932        29072         2980         4880
        ReStructuredText     2621       548840       417105            0       131735
        Ruby                    1           29           25            0            4
        Shell                 556        85666        59725        10972        14969
        SVG                    59        39038        37555         1405           78
        Plain Text           3230       239573            0       197373        42200
        Unreal Script           5          716          446          162          108
        Vim script              1           42           33            6            3
        XSL                    15          300          183           78           39
        YAML                  921        91167        72962         3985        14220
        ===============================================================================
        Total               65340     28511276     20985365      3704703      3821208
        ===============================================================================

~~~
nix23
The Unreal Script is for the new 3D menuconfig ;)

~~~
est31
Someone should replace that with GDscript.

------
blondin
what does linux kernel in-tree support mean? that drivers can be written in
rust or something?

~~~
ndesaulniers
Yes. In tree means their sources are in the Linux kernel git repository, as
opposed to out of tree drivers. In tree drivers are maintained by the
maintainers, so API changes are done together for all in tree drivers. Out of
tree drivers don't get this benefit, and are more difficult to build in my
experience.

~~~
blondin
thank you!

------
golergka
Tangential question: what would be a career path for a typical product
developer to become one of the programming gods who get invited to such
discussions? (Even if it's technically open mailing list, you know what I
mean). How many years of experience and how much formal CS education would it
take to acsend to that level?

~~~
coldpie
Formal CS education is pretty much useless for systems programming. Systems
programming deals with real-world hardware, CS is theorizing about about
fantasy machines. "Computers are to Computer Science what telescopes are to
Astronomy." They're just different fields. They intersect, of course, but
systems programming isn't very near that intersection. Being good at analyzing
a DFA on a Turing machine isn't going to be much help when you need to bang
bits to a non-compliant USB device.

If you want to get into these discussions, you need to be a kernel dev. That
means you need to write kernel stuff. Probably the easiest thing is to write
or improve a driver for some device you have (game controllers; steering
wheels; audio devices; drawing tablets). It's not rocket science, it's all
just bits and bytes and code, just like any other programming.

Edit: Just for an example, here's where the PlayStation controller driver
parses the data it gets from the device into something applications can read
over the input subsystem. Don't be intimidated, there's nothing magic here,
just C code reading data and transforming it. Suppose you maintained this
driver and wanted to re-write it in Rust. You could have some input into the
discussion!
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-
sony.c#n940)

~~~
pjmlp
Except many universities don't teach CS like that, I guess that might be an US
thing.

In the Portuguese university where I took my degree, for example, I had to
write an UNIX floppy device driver, code in 80x86 and MIPS Assembly, implement
my own userspace threading library, implement a distributed algorithm for
maldebrot calculations across a Linux cluster via PWM (MPI predecessor) and
report its scalability varying the amount of available machines on the
cluster, create a compiler, stuff SUN RPC generated stubs with our own
encryption algorithm, implement a B+Tree indexing library using inodes
directly.

All look pretty useful to me.

~~~
ksec
And How long ago was that? :)

I would assume most CS in EU dont teach that anymore.

~~~
pjmlp
Mid-90's, so around 30 years ago.

My former university surely does it, although obviously not with the same
exact content.

[https://www.di.fct.unl.pt/en/education/integrated-master-
com...](https://www.di.fct.unl.pt/en/education/integrated-master-computer-
science/study-program)

------
29athrowaway
The problem I perceive with Rust as a language for Linux, is not that Rust is
not an excellent language. It is that it evolves rather quickly and code may
break when you switch versions.

------
megous
Does rust/llvm even support all the CPU architectures Linux supports?

If not how will that work? Will some drivers be then limited to only some
architectures?

~~~
ndesaulniers
No, but it's already the case that some drivers are already tightly coupled to
an architecture. Does it make sense to build a driver for some internal piece
of hardware from an ARM SoC for PPC? Generally, no.

~~~
megous
The kernel contains vast number of drivers that are for universal buses like
I2C, SPI, USB, PCI(e), SDIO, UART, writing any of these in rust would make
these drivers unavailable to architectures unsupported by llvm. I think that
would be quite sad.

~~~
ndesaulniers
Right. I don't think anyone is proposing ReWrItE iT iN rUsT. There's way way
more drivers that aren't buses (platforms) that don't need the level of
portability we're talking about.

~~~
megous
I'm not talking about buses, but regular drivers for devices on those buses.
The buses are universal, that means that they can be supported on any
architecture, so drivers for devices on those busses should not be limited to
any single arch just by the choice of the language.

------
ausjke
While I like Rust I still picked Modern C++(17) for my next project. All
modern languages are converging these days.

Adopted C++ because of its libraries at large. Will still learn Rust on the
side. For the moment, boring and verified for product especially when they're
updating and remaining up to date.

------
zelly
To bootstrap Rustc you have to compile every single version. Say goodbye to
reproducible builds. Say goodbye to civilians with cheap laptops being able to
compile their kernel.

~~~
hisham_hm
This is a strawman argument. To be reminded of what it takes to truly
"bootstrap" a C compiler, I recommend everyone to read Ken Thompson's Turing
Award lecture "Reflections on Trusting Trust".

~~~
zelly
gcc can still be bootstraped from just an assembler and linker[1] with very
few binaries you have to trust and it is possible on comoddity hardware.
Bootstrapping Rust is so difficult that adding it to Linux would for all
purposes eliminate this feature (being able to be built completely from
source) from Linux, probably leading to a fork of Linux without Rust for those
that care about it.

[1] [https://guix.gnu.org/manual/en/html_node/Reduced-Binary-
Seed...](https://guix.gnu.org/manual/en/html_node/Reduced-Binary-Seed-
Bootstrap.html)

~~~
steveklabnik
mrustc can shorten that bootstrap, and also, many Linux distros already ship a
rustc that they’ve bootstrapped as far back as they thought prudent. So yes, I
can see some folks doing something like this, but I doubt that the major
distros would.

------
Ericson2314
Happy to see happening!

But to get the most value out of Rust, one needs to use the Cargo ecosystem
too (even for kernel code!) and that will be a much bigger political quagmire.

~~~
geofft
We've got Cargo wired up in our prototype, which can let you link modules
against no_std crates on crates.io: [https://github.com/fishinabarrel/linux-
kernel-module-rust](https://github.com/fishinabarrel/linux-kernel-module-rust)

Probably one good end state is if the core kernel exposes appropriate safe
abstractions, and vendors with out-of-tree modules (which tend to be worse at
security than the main kernel) could use those APIs + things from crates.io to
build their modules.

But yes, figuring out how to use useful things that aren't in libcore is one
of the open questions.

~~~
Ericson2314
Glad to hear it! I just hope Linux doesn't end up with the crates.io vendoring
nightmare that the big-corps made for themselves.

------
intc
Hopefully this will not pass - The requirement of having GCC + LLVM + Rust
installed in order to build kernel would be insane.

~~~
Multicomp
As someone new to the dev party who has never built anything more lower level
than a win32 exe, may I ask why that's insane?

Adding 1000 npm dependencies, I see. Adding 1 rustc one? Doesn't SEEM
terrible.

~~~
yjftsjthsd-h
We only just got to a point where 2 C compilers could build Linux; adding
rustc brings us back to a monoculture.

~~~
josephcsible
It sounds like you're saying that you should never use any programming
language until it's supported by at least 2 compilers. Is that accurate?

~~~
codingstream
Without a language specification for Rust, any compiler that isn't the
reference implementation, by definition, cannot be correct. Put another way,
how is a compiler writer supposed to know what is and is not a bug in the
reference implementation?

~~~
steveklabnik
Most languages do not have a specification, and it works out fine.

Rust's is in-progress. There are some things that are well-specified, and
there are some things that are still up in the air.

~~~
moreaccountspls
Right, which is why it's a poor choice for the kernel at this time.

------
Shorel
My only complaint about Rust is terminology.

"Immutable variable" what an oxymoron!

That's what is known as a constant!

A variable is mutable, a constant is not. Was it that hard to understand?

------
staycoolboy
Hmm... Might be time to start looking into Rust. Is it popular in college? I
think that's what made Python displace Java.

EDIT: lol. Decided to dive in a hit this almost immediately:
[https://docs.rust-embedded.org/book/start/io.html](https://docs.rust-
embedded.org/book/start/io.html)

~~~
coldpie
That's the guide to embedded programming. If you're just looking to learn
Rust, start here: [https://doc.rust-lang.org/book/](https://doc.rust-
lang.org/book/)

------
ncmncm
Now there is no legitimate reason to lock out C++.

~~~
JoshTriplett
There are plenty of reasons. As just one of them: C++ is unsafe by default.
There's theoretically a safe subset, but there's no precise or consensus
definition of that subset. There's no type-system or language support for
helping you stay strictly within that subset (and requiring some kind of
marker for if you don't). Often, the most obvious way of doing something is
unsafe; for instance, in C++, arr[i] is unsafe, and you have to write
arr.get(i) to be safe. (In Rust, arr[i] and arr.get(i) are both safe, and you
have to write arr.get_unchecked(i) in an unsafe block if you truly want an
unsafe indexing operation.)

~~~
tptacek
Can you help me understand why locking C++ out of a kernel written almost
entirely in C, and which receives huge volumes of new C code every year,
wouldn't be an instance of making the perfect the enemy of the somewhat
marginally better?

~~~
kdmccormick
Here [1] is one of Linus's more well-known rants about C++. It's in reference
to the Git source, but I think most of it applies to his attitude towards
using C++ in the kernel as well.

[1]
[http://harmful.cat-v.org/software/c++/linus](http://harmful.cat-v.org/software/c++/linus)

~~~
tptacek
Just to be clear, I don't know that anyone in this subthread likes C++. I
stopped writing in it in 2003 and I'm glad to be done with it. (I still adore
C).

------
loosescrews
I have a hard time seeing this happen. Rust has most of the same properties
which prevent C++'s inclusion in-tree. (Look up Linus' opinions on C++ if you
aren't already familiar.)

Further, as far as I can tell, Rust currently lacks mainline GCC support which
I believe will be a blocker.

~~~
photon12
The thing is the kernel is kinda hurting for maintainers and opening up the
path for the next generation of systems programmers (most of whom don't want
to touch C any more than they have to) has to be something Linus is more
likely to prioritize than in previous decades.

~~~
MrBuddyCasino
How would requiring learning Rust, which is famously difficult, be the
solution to that problem?

~~~
xiphias2
Writing safe C and C++ is even much more difficult than writing Rust code
(especially with many developers). And when you are writing kernel code, both
safety and performance are crucial.

~~~
MrBuddyCasino
The problem seems to be to find people who do not just want to write code, but
do the administrative parts:

"We do not have enough maintainers. We do have a lot of people who write code,
we have a fair number of maintainers, but... it's hard to find people who
really look at other people's code and funnel that code upstream all the way,
eventually, to my tree... It is one of the main issues we have."

~~~
nickez
Finding people willing to review rust must be much easier than finding someone
willing to review c.

~~~
xiphias2
Actually I think the answer is yes, as Rust is much stricter to the person
who's contributing the code. If I was asked to review another person's code, I
would much prefer reviewing Rust code, as I would be able to concentrate on
the logic and the efficiency of the code instead of potential low level
mistakes.

The code smell in Rust is usually marked with ,,unsafe'', Boxing / reference
counters, or dynamic behaviour, which is very easy to search for.

~~~
verdagon
Is reference counters really a smell? I thought it was the main way to write
Rust when the borrow checker is too strict for something you want to do.

Vec + generational indices might be the other way, is that preferred over Rc?

~~~
xiphias2
,,when the borrow checker is too strict for something you want to do''

Most of the times it isn't. Just as an example here's a random part of serde,
the high quality serialization library in Rust:

[https://github.com/serde-
rs/serde/blob/master/serde/src/priv...](https://github.com/serde-
rs/serde/blob/master/serde/src/private/de.rs)

The amount of extra automatic memory management is often a good indicator of
not well thought out data structures (although of course they are not always
needed).

------
doonesbury
Formal leaning HN people: Does Rust just have better sales & marketing than
C++? Or is it really better for safety and correctness?

* Rust is NOT a programming language with deep, well-integrated support for proof systems or state exploration e.g. TLA+.

* Rust is no Frama-C where static analysis and function contract support is far more apparent and important

* Rust is not ADA

* The previous items also arise and are quite important as a direct result of generality: to the extent Rust imposes (albeit with benefit) language design to avoid certain kinds of functional issues, those features can later become limitations as a pushy, over opinionated language. Therefore to have flexibility in designing fast code that's yet correct code one usually has to have the low-level ability of C/C++ augmented with formal tools.

I'm not seeing Rust do that. Now, I've made a couple of jokes elsewhere in HN
about Rust's propensity to show up uninvited to every vaguely language issue
and press its case --- ex. I was vacuuming the floor yesterday when Rust
somehow got through the front door and was explaining how a Rust vacuum is so
much better, or how I'd never need to vacuum again if I used Rust. But I am
only half joking.

For the last year I've spent much of my time in GO after getting sick-and-
tired of C++ build/language complexity for the previous 10+ years. I am
somewhat aligned to others who rightly ask if speed is all that matters?
(Recall the Meyers joke about Pavlov training and C/C++ programmers when it
comes to speed).

Correctness counts too and if the compiler spends a little bit more I time I'd
be fine with that if for distributed/parallel programming I've got good
guarantees.

For those who use TLA, SPIN, Frama-C and other formal tools what's your take
on this? I think designers of those kinds of formal tools will be surprised to
learn some of their correctness aims were solved by Rust.

~~~
roca
Rust makes it easy to write code that's very expressive (dynamic memory
allocation etc) and has strong safety properties. Certainly easier than having
to verify with SPARK or Frama-C. Rust's type system, especially traits and
affine types, lets you encode a lot of important properties (e.g. typestates).

Rust does need tools to verify Rust code correctness and especially to verify
unsafe Rust code. There is a lot of work going on in this area: see
[https://alastairreid.github.io/rust-verification-
tools/](https://alastairreid.github.io/rust-verification-tools/) for a sample.

~~~
doonesbury
I'm gonna look at rust; we're a huge c/c++ shop so there's room from
improvement here. Now no program is a spec and implementation in one. Thus
rust ought to be careful about keeping all it's hammers in language alone. If
rust is smart and particularly wants to move to distributed computing or csps
correctness will have to take on more complex meanings that bad index or
divide by zero.

