[zubspace]

It's an interesting discussion. There's always a divide when you slowly migrate from one thing to another.

What makes this interesting is that the difference between C code an Rust code is not something you can just ignore. You will lose developers who simply don't want or can spend the time to get into the intricacies of a new language. And you will temporarily have a codebase where 2 worlds collide.

I wonder how in retrospect they will think about the decisions they made today.

[Sharlin]

Most likely Rust will stay strictly on the driver side for several years still. It's a very natural Schelling fence for now, and the benefits are considerable, both in improving driver quality and making it less intimidating to contribute to driver code. It will also indirectly improve the quality of core code and documentation by forcing the many, many underspecified and byzantine API contracts to be made more rigorous (and hopefully simplified). This is precisely one of the primary things that have caused friction between RfL and the old guard: there are lots and lots of things you just "need to know" in order to soundly call many kernel APIs, and that doesn't square well with trying to write safe(r) Rust abstractions over them.

[Tyr42]

An example of the latter: drm_sched

https://vt.social/@lina/113051677686279824

[renewedrebecca]

> and that doesn't square well with trying to write safe(r) Rust abstractions over them.

Or just using those kernel APIs, period.

[bayindirh]

I don't think changing to Rust code completely is something attainable. I guess some older or more closer to the metal parts will stay in C, but parts seeing more traffic and evolution will be more rusty after some time, and both will have its uses and have their islands inside the codebase.

gccrs will allow the whole thing to be built with GCC toolchain in a single swoop.

If banks are still using COBOL and FORTRAN here and there, this will be the most probable possibility in my eyes.

[leonheld]

> I guess some older or more closer to the metal parts will stay in C

I suppose the biggest reason is that C programmers are more likely than not trained to kinda know what the assembly will look like in many cases, or have a very good idea of how an optimizer compiler will optimize things.

This reminds me I need to do some non-trivial embedded project with Rust to see how it behaves in that regard. I'm not sure if the abstraction gets in the way.

[flir]

Is there a layer where C is the sweet spot? Something too high-level for ASM, and too low-level for Rust? (not my area, so genuine question).

[pyrale]

> I wonder how in retrospect they will think about the decisions they made today.

The decision was not made today, what happens today (or, rather, a few days ago) is Linus calling out a C maintainer going out of his way to screw rust devs. Rust devs have also been called out for shitty behaviour in the process.

The decision to run a Rust experiment is a thing that can be (and is) criticized, but if you allow people to willfully sabotage the process in order to sink the experiment, you will also lose plenty of developers.