Torvalds: You can avoid Rust as a C maintainer, but you can't interfere with it

"C so obviously outdated now" lol...

People could have spawned another kernel branch focused around Rust, but know the predictable outcome:

https://en.wikipedia.org/wiki/Second-system_effect

Thus the novelty bias hijacks peoples ability to reason, and everyone gets upset as the Polyglot rots apart.

Polyglot projects by their very nature inject unstable dependencies into the build tree. This also makes the core feature of bootstrapping Linux on new hardware more difficult.

If someone says it is about learning yet another language, than they are disregarding peoples valid concerns. The kernel should be forked eventually with or without foundation support, if people refuse to isolate a branch with the extensive refactoring mission written in hype.

YMMV =3

And if you look how that mess started out you had cross site scripting on the frontend because html allowed you to inject more javascript from everywhere and SQL injection on the backend because you had to translate your input from one language to another with tools that went out of their way to interpret data as commands.

The modern web is a gigantic mess with security features hacked on top of everything to make it even remotely secure and the moment it hit the desktop thanks to electron we had cross site scripting attacks that allowed everyone to read local files from a plugin description page. If anything it is the ultimate proof how bad things can go.

I've mostly seen language mixing in frontend. Backends seem to end up either being completely ported to a new (compatible) language, or experimental new languages get ported back. Perhaps frontend developers are just more versatile because they have to, with frameworks and the base spec constantly shifting under their feet.

Even many backend devs seem to shy away from things like SQL because they're not too comfortable with it. Which isn't bad per se, it's very easy to make a small mistake in a query that crushes the database, just a personal observation of mine.

While I think your points about some of the difficulties that arise in multi-language/framework projects is fair, I sort of roll my eyes whenever someone frames Rust as something like the "hip new thing".

The Linux kernel's first "release" was in 1991, hit 1.0 in 1994, and arguably the first modern-ish release in 2004 with the 2.6 kernel. Rust's stable 1.0 release was in 2015, 13 years ago. There are people in the workforce now who were in middle school when Rust was first released. Since then, it has seen 85 minor releases and three follow-on editions, and built both a community of developers and gotten institutional buy-in from large orgs in business-critical code.

Even if you take the 1991 date as the actual first release, Rust as a stable language has existed for over 1/3 of Linux's public development history (and of course had a number of years of development prior to that). In that framing, I think that it's a little unfair to include it in the "hip new thing" box.

[delayed]

Other than the choice problem of deciding what language to build new features in (which needs a clear policy), I don’t see why maintaining a mixed language codebase HAS to be terrible.

In my current job, also at FAANG, my team (albeit SRE team, not dev team), owns moderately sized codebases in C++, Go, Python and a small amount of Java. There are people “specialised” in each language, but also everyone is generally competent enough to at least read and vaguely understand code in other languages.

Now of course sometimes the issue is in the special semantics of the language and you need someone specialised to deal with it, but there’s also a large percentage which is logic problems that anyone should be able to spot, or minor changes which anyone can make.

The key problem in the situation you described seems to be the dysfunction in the teams about arguing for THEIR side, vs viewing the choice of language as any other technical decision that should be made with the bigger picture in mind. I think this partly stems from unclear leadership of how to evaluate the decision. Ideally you’d have guidance on which to prioritise between rapid development and consistency to guide your decisions and make your language choice based on that.

As your codebase scales beyond a certain point, siloing is pretty inevitable and it is better to focus on building a tree of systems and who is responsible for what. However that doesn’t absolve especially the leads from ONLY caring about their own system. Someone needs to understand things approximately to at least isolate problems between various connected systems, even if they don’t specialise in all of them.

I don't know if its golden rule or common-sence when applicable.

If our testing framework is in Python; writing a wrapper to code tests for your feature in Perl because you're more comfortable with it is the Wrong way to do it imo.

But if writing a FluentD plugin in Ruby solves a significant problem in the same infra; the additional language could be worth it.

Everything is about tradeoffs.

Is that possible? Could C add a borrow checker? Honest question, I have no idea how anything works

This is Hector Martin, a formal contributor who threatened social media attacks on kernel maintainers if they did not implement rust into the kernel.

After writing some non-trivial and performance sensitive C/C++ code, you have feeling of how that code behave on the real metal. I have that kind of intuition, for example. I never had to dive to the level of generated ASM, but I can get ~80% of theoretical IPC with just minding what I'm doing in C++ (minimum branching, biasing branches towards a certain side, etc.).

So, I think if you do the same thing with Rust, you'll have that intuition, as well.

I have a friend who writes embedded Rust, and he said it's not as smooth as C, yet. I think Rust has finished the first 90% of its maturing, and has the other 90%.

> 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 is the only way Hellwig's objection makes any kind of sense to me. Obviously, intra-kernel module boundaries are no REST-APIs, where providers and clients would be completely separated from each other. Here I imagine that both the DMA module as well as its API consumers are compiled together into a monolithic binary, so if assumptions about the API consumers change, this could affect how the module itself is compiled.

I've done a non-trivial embedded project in C. (Quadcopter firmware). The language doesn't get in the way, but I had to write my own tooling in many areas.

Many people still have the mistaken belief that C is still trivial to map to assembly instructions and thus has an advantage over C++ and Rust in areas where understanding that is important - but in practice the importance is overstated, and modern C compilers are so capable at optimising at high optimisation levels that many C developers would be surprised at what was produced if they looked much further than small snippets.

Like half the point of high-level systems languages is to be able to express the _effects_ of a program and let a compiler work out how to implement that efficiently (C++ famously calls this the as-if rule, where the compiler can do just about anything to optimise so long as it behaves in terms of observable effects as-if the optimisation hadn't been performed - C works the same). I don't think there's really any areas left from a language perspective where C is more capable than C++ or Rust at that. If the produced code must work in a very specific way then in all cases you'll need to drop into assembly.

The thing Rust really still lacks is maturity from being used in an embedded setting, and by that I mostly mean either toolchains for embedded targets being fiddly to use (or nonexistent) and some useful abstractions not existing for safe rust in those settings (but it's not like those exist in C to begin with).

The exact reason why it was created in first place, a portable macro assembler for UNIX, and should stayed there, leaving place for other stuff on userspace like Perl/Tcl/... on UNIX, or Limbo on Inferno, as the UNIX authors revised their ideas of what UNIX v3 should look like, already on UNIX v2 aka Plan 9, there was a first attempt with Alef.

Or even C++, that many forget was also born at Bell Labs on the UNIX group, the main reason being Bjarne Stroutroup never wanted to repeat his Simula to BCPL downgrade ever again, thus C with Classes was originally designed for a distributed computing Bell Labs research project on UNIX, that Bjarne Stroutroup certainly wasn't going to repeat the previous experience, this time with C instead of BCPL.

Directly programming hardware with bit-banging, shifts, bitmasks and whatnot. Too cumbersome in ASM to do in large swaths, too low level for Rust or even for C++.

Plus for that kind of things you have "deterministic C" styles which guarantee things will be done your way, all day, every day.

For everyone answering: This is what I understood by chatting with people who write Rust in amateur and pro settings. It's not something of a "Rust is bad" bias or something. The general consensus was, C is closer to the hardware and allows handling of quirks of the hardware better, because you can do "seemingly dangerous" things which hardware needs to be done to initialize successfully. Older hardware is finicky, just remember that. Also, for anyone wondering. I'll start learning Rust the day gccrs becomes usable. I'm not a fan of LLVM, and have no problems with Rust.

Rust is a systems programming language by design; bit-banging is totally within its remit, and I can't think of anything in the kernel that Rust can't do but that C could. If you want really, really tight control of exactly which machine instructions get generated, you would still have to go to assembler anyway, in either Rust or C.

maybe generic implementations of crypto primitives and math kernels.

For the world servers and supercomputers to run on Windows.... /s