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.
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.
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.
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.
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.
Basically just “but two languages is HARD”
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.
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!
Yeah, even Linus said he wasn’t 100% sure it was gonna succeed but how else do you know unless you try it.
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.
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.
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.
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.