ojeda · HackerTrans

há 4 mesesdiscuss

I like Visual Studio, and have used it for C++. And, yes, it would be great if they add native support for Rust.

But that would not make me pick C++ over Rust. Other requirements may.

ojeda

há 4 mesesdiscuss

My reply was about Win32 and typical C++ development. Obviously other projects may be best written in C# or other languages and frameworks.

Anyway, Microsoft is the one providing the Rust crate(s) I linked, and according to the releases it seems they are using them internally too. I do not see what is "nonsensical" about using them, and I have used them in the past just fine, just like I used Win32 from C++ in the past.

ojeda

há 4 mesesdiscuss

Yeah, Win32 (Windows API) will be around for a long time one way or the other, and there is a ton of tooling and docs around it. Even for non-Windows usage it is to be considered in certain situations.

> Don't be swayed by the propaganda. Especially if your application has essentially no untrusted input.

Even without untrusted inputs, in 2026 one should think twice before selecting C++ for a new project. There are still some reasons to do so, of course, but Win32 isn't one of them -- one can use it from a memory safe language just fine, e.g. https://github.com/microsoft/windows-rs

ojeda

há 4 mesesdiscuss

> which indicates the undefined behavior actually helps rather than hurts when used with good tooling

No, one doesn't need undefined behavior for that at all (which does hurt).

What actually helps is diagnosing the issue, just like one can diagnose the unsigned case just fine (which is not UB).

Instead, for this sort of thing, C could have "Erroneous Behavior", like Rust has (C++ also added it, recently).

Of course, existing ambiguous C code will remain to be tricky. What matters, after all, is having ways to express what we are expecting in the source code, so that a reader (whether tooling, humans or LLMs) can rely on that.

ojeda

ano passadodiscuss

> The Rust Project says R4L is a “flagship” goal

Rust's 2024H2 and 2025H1 flagship goals are about getting Rust for Linux into stable Rust, implementing features we need and so on. We really appreciate being a flagship goal of theirs! We collaborate regularly, and some members are part of both projects, and so on and so forth.

But that does not mean one is driven by the other, just like GCC and Clang do not drive the Linux kernel because they introduced features to build it. They support us, which is different.

> Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.

I wrote the document, but I never resigned since I started the project -- you are probably referring to Wedson. I have seen articles that confused both of us in the past, so that is not a surprise, though I wouldn't mind to have Wedson's mind around from time to time :)

The FOSDEM 2025 keynote has some details about the history of the project. There is an LWN article about it: https://lwn.net/Articles/1007921/

I hope that clarifies.

ojeda

há 4 anosdiscuss

N2834 ("Deprecate the %n format specifier in C2X") was discussed in WG14 (no consensus).

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2834.htm

ojeda

há 5 anosdiscuss

"Interface files" that are intended as a form of documentation should be generated automatically instead.

As for interface vs. implementation docs, nothing precludes having both in a single file either.

ojeda

há 5 anosdiscuss

C++ may get pattern matching with P1371, which may make visiting look more reasonable:

    std::string_view print_type(const variant_type& jtt) {
        using namespace std::literals;
        return inpect (jtt) {
            <double> __ => "Number"sv;
            <bool> __ => "Bool"sv;
            ...
        };
    }

In any case, `std::variant` should have been a language feature all along, instead of a library one; cf. Rust:

    enum Value {
        Number(f64),
        Bool(bool),
        ...
    }

    fn print_type(v: &Value) -> &str {
        match v {
            Value::Number(_) => "Number",
            Value::Bool(_) => "Bool",
            ...
        }
    }

ojeda

há 5 anosdiscuss

For C, there is a paper (pending publication) about this. No promises, of course, but the committee will at least have a look.

ojeda

há 5 anosdiscuss

> Zig and Rust are safe languages

Zig is a nice improvement over C, but it is not safe.

There is work in progress (https://github.com/ziglang/zig/issues/2301), but from what I can tell, key details are still to be decided, including the classes of errors that will be covered, whether they will require runtime tracking, etc.

In my opinion, Zig should look into becoming UB-less -- listing undefined behavior instances like the C standard does or enabling safety only in some build modes is not enough.

ojeda

há 5 anosdiscuss

To be fair, I was just a teenager back then and I was out of kernel development for quite a few years afterwards.

But you are right, this is not coming from the Rust community itself. In fact, several independent groups have been thinking of using Rust in one way or another for kernel purposes, as early as... 2013 (!), e.g. from Taesoo Kim:

    https://github.com/tsgates/rust.ko/commit/58f0fb8fdf4063f5b24a09cbfeec81bf28a9d81b

There were others: John Baublitz had a external kernel module going on, Samantha Miller also worked on enabling a FUSE-like API to write filesystems in Rust, etc. And, of course, Alex Gaynor & Geoffrey Thomas had the most mature Rust abstractions for external kernel modules.

At the moment, in the project we have a mixture of people that come from a Rust or kernel background, which has been great. And most of us have used many languages in our work, not just Rust. Personally, most of my career has been around C++ and Python.

ojeda

há 5 anosdiscuss

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

ojeda

há 5 anosdiscuss

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

comments