Mixing Rust and C in Linux likened to cancer by maintainer : linux

[–] azertyfun@sh.itjust.works 68 points 2 weeks ago (2 children)

Don't force me to deal with your shiny language of the day,

WE HavE LegItImaTe COnCeRNs

Exact same shit as last time, some cranky old dude with the territorial instinct of a bulldog sabotages anything to do with rust under a very thin layer of so-called technical concerns, yet refuses to partake in constructive discussion. Like, literally, the changeset is just bindings in rust/kernel? What even is there to complain about regarding maintainability of kernel/dma, given that as far as I can tell the rust devs will deal with any future incompatibilities?

Very shameful for the kernel community that this kind of aggressive sabotage is regular and seemingly accepted. The incessant toxicity is not a good look and very discouraging to anyone thinking of contributing.

[–] cm0002@lemmy.world 37 points 2 weeks ago (1 children)

A C/C++ dev acting this way‽ Well I am shocked, SHOCKED!

[–] devfuuu@lemmy.world 10 points 2 weeks ago

And they wonder why the rest of the world wants to avoid and run away from that language and culture.

[–] jwt@programming.dev 3 points 2 weeks ago

He might even have legitimate concerns, but this response is just so unconstructive. It's solely aimed at slighting other programmers.

[–] nichtburningturtle@feddit.org 32 points 2 weeks ago (2 children)

That's right. We need to rewrite it in a REAL language like java.

[–] henfredemars@infosec.pub 17 points 2 weeks ago (2 children)

I think you forgot the -Script.

[–] fxomt@lemm.ee 2 points 2 weeks ago* (last edited 2 weeks ago)

You forgot the -fuck

[–] nichtburningturtle@feddit.org 1 points 2 weeks ago

That more or less is possible / exists https://github.com/ading2210/linuxpdf

[–] metaStatic@kbin.earth 10 points 2 weeks ago (1 children)

COBOL or GTFO

[–] Blaster_M@lemmy.world 4 points 2 weeks ago (1 children)

FORTRAN my man

[–] devfuuu@lemmy.world 1 points 2 weeks ago

Haven't you heard? Fortran faster than C now.

[–] sxan@midwest.social 23 points 2 weeks ago (4 children)

Rust is dead. Haven't you heard? We're rewriting everything in Zig now.

Rust should be deprecated.

On a more serious note, having a CTO at Microsoft, of all places, jump in on your side is kind of embarrassing. With one exception, code written at Microsoft has been some of the worst, most insecure, in the world.

[–] Laser@feddit.org 8 points 2 weeks ago (2 children)

Rust is dead. Haven't you heard? We're rewriting everything in Zig now.

I don't think the broader zig community has the rewrite spirit that the rust community has. For Rust, this mentality was also motivated by an increased security, which zig does improve over plain C, but not to the extent Rust does.

To preface anything that follows, I'm not a developer, so this is little-informed opinion.

Writing in rust just doesn't seem very enjoyable. It's a language with security in mind, which is a good thing. However, zig also isn't inherently insecure (though it doesn't provide the same security guarantees) and coding in it just seems so much more pleasant. To me, the language makes more sense, which is also something I like about Go. Even manual memory allocation looks well-designed. At no point did I look at zig and thought "oh, that's an odd choice".

The language isn't frozen yet though, so everything you write in it may require changes later on, so I wouldn't recommend it for anything in production. Notably, there's no built-in async or something comparable. If you're fine with these limitations, go ahead and try it out, and if you feel like it, maybe even rewrite an existing tool in it.

ncdu for example is such a tool where the original author rewrote it in zig for version 2.

[–] natecox@programming.dev 8 points 2 weeks ago

Enjoyable is so subjective.

I now write basically all of my projects in Rust because I find the language so enjoyable. I like it so much that it has ruined my desire to continue working on existing projects… because they aren’t written in Rust.

[–] sxan@midwest.social 1 points 2 weeks ago

I think we're mostly on the same page.

Years ago, after over a decade making fistfuls of money as a Java developer and yet becoming almost physically nauseous at the idea of having to look at more Java code, I did a survey of possible ships to jump to. I was on the management track by that point - still more level enough to have my hand in - but salaries weren't a huge factor. So I wrote a series of projects in three upcoming languages at the time: Vala, Rust, and Go.

I don't remember now why Vala dropped out so quickly; I think it was some unsavory dependency or relationship with Gnome libraries, but honestly I don't recall.

But I hated Rust. It felt like a language I was constantly fighting with, and simple, common things were just hard. And it's not like I didn't have experience with other paradigms; I cut my teeth on C and Pascal, did a fair amount of Scheme in college, actually implemented a project in Haskell that went into production at one company (and, for that, I sincerely apologize to every developer who worked there after me), and was part of a team that built an ETL engine for what qualifies as "big data" in Erlang at another.

Rust was the worst developer experience of them all, including Erlang, and that's saying something.

Go was stupid easy to write, and more importantly, to understand other people's code, and relatively hard to write bad code in. It's gotten worse over time (Go generics are practically useless compared to the amount of cognitive complexity they add) but that's the hubris of language developers: they can't resist adding new crap that's just enshittifies the language. Although, in the case of generics, there was a solid decade of pressure, mostly new converts who hadn't yet learned they are entirely unnecessary, to add generics, so I don't really blame the Go team for that one. And, for the most part, they've avoided making large, bad additions.

In any case, I was roasting Rust, not Go.

I love the binaries from Rust projects: they're small (smaller than Go, without the runtime overhead), they're fast, and they're usually statically linked. But the language itself is a nightmare, and the compile times are absurd, so it someone wants to give me a binary, fine. Otherwise, no thanks. Rust may be a "memory safe" language, but that doesn't mean shit if the code isn't auditable and people are just passing around binaries.

Re auditability: sure, a Rust programmer could audit a code base. But I'd argue that a non-Go developer with any experience with any C-ish language could audit a Go project and confirm that it's not doing any sketchy things like calling out to a botnet. I doubt many people would claim the same for Rust.

[–] lengau@midwest.social 3 points 2 weeks ago

With one exception

Whoa, it's not after I find someone else who worked at my last employer!

[–] The_Decryptor@aussie.zone 2 points 2 weeks ago (1 children)

On a more serious note, having a CTO at Microsoft, of all places, jump in on your side is kind of embarrassing.

That comment was from a few years ago and wasn't in relation to Linux, and the company he co-founded made some pretty useful things (And revealed the Sony rootkit in 2005) before MS bought them.

[–] sxan@midwest.social 1 points 2 weeks ago

Oh, that changes things. Founding a company and being an executive when Microsoft acquires you - well, it doesn't necessarily make you technically competent, but it does make you a certain kind of smart.

[–] refurbishedrefurbisher@lemmy.sdf.org 1 points 2 weeks ago (1 children)

Is that one exception Xbox?

[–] sxan@midwest.social 3 points 2 weeks ago

Excel. Before it got subsumed and was infected with the ribbon. The Excel team were truly talented developers.

I think much of that was part and parcel out Microsoft acquiring them when they bought Excel, and it's obviously degraded in the interim, but for a while they were all island of programming excellence in the Sargasso Sea of usual Microsoft incompetence. The only thing Microsoft is really good at has ever been marketing and sales, and they weren't even good at staying on the ethical, legal side of business operations.

[–] burgersc12@mander.xyz 14 points 2 weeks ago (2 children)

Basically just "but two languages is HARD"

[–] deadcream@sopuli.xyz 22 points 2 weeks ago (2 children)

It is hard when you mix them in one codebase and need bindings and wrappers for interoperability. This always introduces additional work and maintenance burden. It's always a tradeoff and for most projects not worth the effort. Tech corporations that do this regularly have dedicated teams to deal with boilerplate bullshit and tooling issues, so that regular devs can just code with minimal friction. Rust-in-Linux community decided to take it upon themselves, but I'm not sure if they can keep it up for years and decades in the future.

Though gradually getting of C is still a good idea. Millions of lines of C code is a nightmare codebase.

[–] burgersc12@mander.xyz 14 points 2 weeks ago

Yeah, even Linus said he wasn't 100% sure it was gonna succeed but how else do you know unless you try it.

[–] FizzyOrange@programming.dev 2 points 2 weeks ago

It is hard, but what's the alternative? Does Linux want to be comically insecure forever?

I know Linus doesn't really care about security so it's kind of surprising that he is on board with Rust!

[–] henfredemars@infosec.pub 14 points 2 weeks ago (1 children)

I'd even have sympathy for this argument that introducing another language is a major undertaking (and it is!) but Linux is already full of lots of other languages (Macros, Makefile, Shell, BPF, assembly languages, Perl, Python scripts...) and developers are willing to do the work to use a language that helps solve problems Linux cares about.

[–] deadcream@sopuli.xyz 17 points 2 weeks ago (2 children)

That's not a good argument. Most of these additional languages are used for separate things, like build scripts and stuff. They don't affect actual kernel code which is C and assembler language.

[–] Corbin@programming.dev 6 points 2 weeks ago

Your argument is completely specious. Re-read that list. Assembly is a second language in the kernel already, and really it's multiple languages, one per supported ISA. Perl and Python scripts are used to generate data tables; there are multiple build-time languages. eBPF is evaluated at runtime; the kernel contains bytecode loaders, JIT compilers, and capability management for it. The kernel has already paid the initial cost of setting up a chimeric build process which evaluates many different languages at many different stages.

[–] henfredemars@infosec.pub 3 points 2 weeks ago* (last edited 2 weeks ago)

Perhaps not, but if you’re a kernel developer, I believe you are obliged to understand your build system and tooling. The fact of the languages aren’t all used at runtime seems immaterial.

That said, I am no kernel developer, so take it with a grain of salt.

[–] parpol@programming.dev 13 points 2 weeks ago

About time they retired C. Oh, that's not what happened?

[–] mox@lemmy.sdf.org 12 points 2 weeks ago* (last edited 2 weeks ago)

And? The GNU General Public License and every project that uses it (including Linux) have also been likened to cancer, as have many other things that impose and spread their conventions/restrictions/requirements when added to larger systems.

The phrase "going viral" works similarly. These metaphors may not be pretty, but they are not uncommon or inaccurate, either. Stirring up drama around their use doesn't help the project or the community.

[–] 0x0@programming.dev 6 points 2 weeks ago

"Linux is a cancer that attaches itself in an intellectual property sense to everything it touches," Ballmer said, back before Linux had metastasized into the Windows Subsystem for Linux.

Nice writing.

[–] laranis@lemmy.zip 1 points 2 weeks ago

Brain read it as "linked to" and still said, "Yup, that tracks."

[–] Cypher@lemmy.world -4 points 2 weeks ago (1 children)

Hellwig has some excellent points and people are up in arms solely because he’s not giving the green light for the shiny new toy.

Keep the wrappers in your code instead of making life painful for others

This is a perfectly valid approach, anyone claiming he’s resistant for no reason has never tried maintaining a multi language code base.

If you want to use something that's not C, be that assembly or Rust, you write to C interfaces and deal with the impedance mismatch yourself as far as I'm concerned.

Again an entirely reasonable approach. There is precedence for this approach in the kernel/dma and I see no reason to change this now, unless a full kernel/dma rewrite to Rust were to occur.

[–] edinbruh@feddit.it 21 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

What they are asking is not to change the c code to suit rust, but to leave the C code as is, and have a single Rust-written wrapper that links into the C DMA code so that other Rust drivers can link into the wrapper. Additionally, said wrapper is not to be maintained by Hellwig, but by the maintainers of the drivers that will use the wrapper, so without overhead for Hellwig.

He is not asking to not make his work harder, he's explicitly asking to make it harder to write rust drivers that use DMA.

[+] Cypher@lemmy.world -7 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

So you think Hellwig doesn’t understand what is and isn’t intended to go into the kernel/dma that dma maintainers would then be responsible for?

You don’t seem to be familiar with either the full conversation the developers had (its all available) or you don’t understand how the Linux project is structured and maintained.

From the email chain:

On Thu, Jan 16, 2025 at 02:17:24PM +0100, Danilo Krummrich wrote:

Since there hasn't been a reply so far, I assume that we're good with maintaining the DMA Rust abstractions separately.

No, I'm not. This was an explicit:

Nacked-by: Christoph Hellwig

And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-languagecodebase and not rust itself, just to escape the flameware brigade).

[–] Corbin@programming.dev 7 points 2 weeks ago (1 children)

Martin's already in the list of maintainers for another subsystem; this is a territorial play by Hellwig. Any kernel developer would recognize this; you don't seem especially familiar with kernel social dynamics either! Also please fix your formatting if you're going to copy-and-paste rather than linking.

[–] Cypher@lemmy.world 0 points 2 weeks ago

Martin is not a maintainer of the Kernel/DMA which is why Hellwig clearly states he doesn’t want to add another maintainer when rejecting Martin’s offer to be a maintainer of this proposed code.

This is very clear if you read the email. If you don’t like the formatting go read the full email chain yourself, you will know where to find it if you’re so familiar with ‘kernel social dynamics’.

[–] edinbruh@feddit.it 5 points 2 weeks ago

I think Hellwig understands everything very well, he just wants things done his way, for whatever (possibly valid) reason he might have.

Literaly from your quotation: "I assume that we’re good with maintaining the DMA Rust abstractions separately [...] No, I'm not" He understands the abstractions would not be in his domain and maintained by someone else, he does not want abstraction at all.

Maybe you are not familiar with the proposal but these "separate rust abstractions" would be a separate module that depends on DMA mapping as a client and deals with cross-language issues, rust drivers would then be clients of this module, it would not be part of the DMA mapping module, it would not be mixed with the DMA code. But Hellwig doesn't want an abstraction module at all, Instead he want's you to "do that [the abstraction] in your driver so that you have to do it [maintain a cross-language codebase]".

Please notice that the abstraction module would not add any more burden on him than the drivers themselves would, because as of now C code is allowed to break Rust code. It would only remove burden from maintainers of Rust drivers, and even if it weren't it would be easier to fix just the abstraction instead of every driver.

He also refuses to have other people maintain the abstraction, this too for whatever reason, which accredits his request to not add abstraction he would have to maintain. If the abstraction were part of the core dma mapping code, I think it would be a reasonable request, but it wouldn't be.

Now, we do not know the reason why he opposes it so much. From his words it looks like he doesn't want Linux to be a cross-language codebase, which would be a valid reason in itself, but dealing with abstractions in drivers instead of a module doesn't make it any less cross-language, unless the drivers are out of tree, which they wouldn't be. Some people (e.g. Hector Martin) think that he's hoping the Rust for Linux project to fail altogether, and fore rust code to be removed from the kernel, and this obstruction would partake in that. I do not think it is that drastic, I think he just fears that those abstraction would eventually become part of what he has to maintain, and no amount of reassurance or new maintainers would change his mind.

I also don't think Martin's brigading is anything productive, and I hope that doesn't become the reason that rust code gets obstructed from being merged into the kernel, but it sure does focus the attention on these matters.