[ojeda]

> the almost complete lack of empiricism in Computer Science

Claiming that an entire science field "lacks empiricism" is quite brave, and definitely false in the case of CS.

Perhaps you are talking about software engineering in practice instead, but that is false too (for any serious project).

> "Nevertheless, we believe that, even today, the advantages of using Rust [in the Linux kernel] outweighs the cost." Where is the evidence?

Three sections of the RFC are spent on characterizing the sentence you quote. The LWN article is not the RFC.

Furthermore, many of the claims I wrote in the RFC are simple facts (e.g. features that Rust has) that you can easily corroborate. For other claims, you can look up plenty of articles, scholarly and otherwise, about Rust benefits.

But none of that really matters, because the only way to gather the evidence you are actually requesting (Rust in the Linux kernel) is getting into the kernel and evaluating Rust after a while.

> "Rust is obviously a better choice for Linux than C."

The RFC does not claim it is "obviously" a better choice.

Quite the opposite, in fact: see the "Why not?" section.

[bjourne]

> Claiming that an entire science field "lacks empiricism" is quite brave, and definitely false in the case of CS.

> Perhaps you are talking about software engineering in practice instead, but that is false too (for any serious project).

I'm not the first one lamenting the lack of experimentation in CS. See https://www.cs.princeton.edu/~jrex/teaching/spring2005/fft/m..., http://www.inf.fu-berlin.de/inst/ag-se/teaching/S-Komponente..., https://ieeexplore.ieee.org/abstract/document/1027796, https://ieeexplore.ieee.org/abstract/document/4221632

> Three sections of the RFC are spent on characterizing the sentence you quote. The LWN article is not the RFC.

I know, but it doesn't contain (empirical) evidence.

> But none of that really matters, because the only way to gather the evidence you are actually requesting (Rust in the Linux kernel) is getting into the kernel and evaluating Rust after a while.

That's the medical equivalent of giving the patient an unknown drug to see what happens. Did the patient get better? Maybe it was the drug! Did the patient get worse? Maybe it was not the drug!

A better way could be to fork a less-visible (but still well-maintained) C project and rewrite it in Rust. If the defect rate over time is significantly lower than for the upstream C project then that is empirical evidence in support of a Linux rewrite in Rust. Running such an experiment would take a lot of time and effort, but that is no excuse for not doing it.

[ojeda]

> I'm not the first one lamenting the lack of experimentation in CS. See ...

Take your first IEEE paper's abstract:

"Empirical software engineering research needs research guidelines to improve the research and reporting processes."

They are pointing out problems with the empirical research that is being done, not claiming "almost complete lack of empiricism in Computer Science" as you did.

There are issues in all science fields, their research, their statistics and their reporting, in particular outside their major journals (and not even those are infallible). Calling out an entire science field in particular is quite insulting to all their researchers.

> I know, but it doesn't contain (empirical) evidence.

Empirical evidence of what? Please do not remove/ignore parts of my reply to suit your argument.

You may claim that you would prefer the RFC to include references to papers and articles; but you cannot claim the evidence does not exist ("99% or so of all new tech can't demonstrate any benefits") or that an entire field has no clue ("the almost complete lack of empiricism in Computer Science").

> That's the medical equivalent of giving the patient an unknown drug to see what happens. Did the patient get better? Maybe it was the drug! Did the patient get worse? Maybe it was not the drug!

No, it is not equivalent, because we are not unconditionally adding Rust into the kernel (much less "rewriting it" as you claim). In fact, one is free to have a C and a Rust version of the same driver and compare whatever metrics you need. Even the RFC contains such an example and I am aware of at least one company doing precisely that.

Moreover, Rust is not an "unknown language" in the sense of an "unknown drug". On the contrary: it was explictly designed to address some issues such as memory-safety.

> A better way could be to fork a less-visible (but still well-maintained) C project and rewrite it in Rust. If the defect rate over time is significantly lower than for the upstream C project then that is empirical evidence in support of a Linux rewrite in Rust.

Not really, because 1. you would need to show the same results would apply to the Linux kernel and 2. we are not rewriting the kernel in Rust.

> Running such an experiment would take a lot of time and effort, but that is no excuse for not doing it.

As mentioned, I am aware of at least one company running an even better experiment than the one you propose.

If you want faster results, then you will need to put money into it yourself.