I think parts of an OS can and should be written in something rust like, however the whole thing should probably not be written in rust.

My personal thought is that C and C++ 98 era are bad, but they were what we needed at the time. Part of this badness was that you could do anything but exact facilities for specialized tasks had to be rolled from scratch. Libraries are possible, but not ideal (no namespaces for C and crazy header + recompile issues for both).

In order to replace C and C++ we need more than just one language, we need an entire family of languages that all have the specific features implemented to support their domain. Rust can probably be used in game programming, but Zig (or in theory eventually Jai) is being specifically made with that goal in mind so they will probably be better. Rust itself will be much more useful for applications that cant stomach managed languages (ie web browsers, etc) because that's what they are specifically building it to do. It's got high level features in a form factor that you would expect from C#/Java with low runtime and no GC.

We can probably write OSes in Rust or Zig, but ideally someone who really likes thinking about OSes will create a language specifically geared towards writing OSes that will be able to replace C.

C++ is the industry standard for existing software but it would be dubious at best to start a new project in C++. Especially something that has essentially no dependencies like a compiler. GUIs and games, sure.

Rust is already approaching C++ in complexity, surpassing it in some places; and also in expressive power, but not surpassing it anywhere yet.

If Rust does not end up fizzling (which is still very possible!), Rust programmers will generally be drawn from the same population as C++ programmers. They will be people who want and can use a powerful language to make themselves more productive and able to manage bigger projects, without need to worry that they are taking a performance penalty, or losing control of details that matter.

Users of Zig, like of Nim and C, will be those uncomfortable with language power, disinclined to automate. Their attention is not on software and what they can build of it, but on problems where a thin veneer of software can add something useful. When there is not much for the software to do, you don't need much power to get it doing that.

"C and C++ are kings when it comes to writing efficient software and the C ABI is the lingua franca of software interoperability, allowing C libraries to be used by almost any other language."

"This ubiquity, coupled with the rise of free and open source software development, has created over the course of the last 40 years a humongous collection of libraries and tools that make up what can be rightfully described as the critical infrastructure of modern software."

For me these observations make it a no-brainer in deciding what language to invest time in learning as an end user writing programs for the authors own use. If C is going to disappear or become irrelevant in favour of something else for writing small, fast and portable software, I will be long dead by that time.

Reading https://kevinlynagh.com/rust-zig/ more or less settled for me any decision over whether to learn Zig or Rust if I had to make that choice.

Rust seems like a magnet for complexity fetishists and people who want to rewrite and "replace" existing software instead of leveraging and maintaining it. I just dont have that kind of time.

If there are any Rust experts around...what am I missing? The way I see it, Rust is still fundamentally designed to work at a higher level of abstraction than C, and is still mostly dependent on C (even C++ really, due to LLVM/Clang). And bare metal or "first compiler" support for bare metal doesn't seem like it's really intended to be a first class use case. At least that's my impression of the ecosystem from the little time I've had to play around with it.

Is this mostly just a thing to get more young people interested in kernel development...allowing them to start out in less important areas and in a language they are passionate about? Or is this a serious proposal about the future of operating systems and other low level infrastructure code? Do you just program everything in unsafe mode? What about runtimes?

It seems to me that Rust isn't even really intended to compete with C for the use cases in which C is dominant in 2023. Every indication is that for "serious Rust in production programming" it's mostly a C++ crowd. Whereas for myself and most of the C programmers I know, Zig has sort of filled that similar space and seems to take the concerns of C programmers more seriously and the team has an attitude more in line with the C culture than the Rust team does. I could spend hours writing examples of this but it's even apparent in the way the Zig team has handled its relationship with LLVM, where they seem very serious about trying to not accept it as fundamental to their language and eventually even eliminate the dependency on the C++ code...with Rust it doesn't seem like this is even on the minds of most of the users. It's purely a dependency for them and that isn't seen as being fundamentally at odds with the intended use cases. That is totally okay...but it ain't the C culture if we are to accept that such a thing exists.

> I'm simply disputing your general claim that moving away from C would not help

I never said such a thing, I said we don't know. As always, in theory, there is no difference between theory and practice; in practice, there is.

* The kernel already contains some C++ which (if you ask C programmers) is not C. And many C programmers are more likely to accept Rust than having to deal with C++.

* AFAIK there is not gcc front-end for Rust yet but LLVM tools can compile the kernel, too. When Rust stabilizes gcc support may come, too.

* The barrier for entry could be lowered by using Rust for Rust programmers if it is employed in some specific modules. The resulting code could be more clear. Not everything in the kernel is pointer pointing and bit shuffling.

* The number of architectures that Rust supports are growing daily.

To some extent. Rust, due to relying on LLVM, is limited by its available targets; and so cannot enjoy the full access that C/C++ can. The same is true for Zig, however, since it does not compile to C.

There probably is still a niche for a simpler language than Rust or C++, but I don't see Go fulfilling that niche. Zig seems like the strongest candidate here.

Yes Rust helps bring in the next generation of Linux devs. It needs to to survive. But it's not because young people like Rust, it's because C developers like rust too.

Yes, Rust has unsafe and unsafe rust is trickier to get right, but you use it opt in and it's only a small amount if the code. Zig is still having unsoundness bugs in relatively simple code

Do you think there will be a trend "back" to using C or C++ for systems programming? I would bet against it. I do believe, by the way, that C has stopped evolving (which is good) and that C++ should stop evolving as well.

Or do you think the replacement of old languages by new ones will accelerate? So in 30 years most systems programming will be done in a language that doesn't exist yet? Maybe not done at all in a "programming language" as we have today?

Or do you think Rust is clearly losing out to some other new languages for systems programming, such as Zig, and will never be popular enough in the first place to enter the "slowly dying legacy" regime?

So languages like Rust are relegated to picking up the new greenfield codebases and some few codebases where engineers felt courageous enough to introduce it.

Overall, the signs are good though. I think it's much easier to onboard new engineers to Rust rather than to the company specific dialect of C++.

Any argument that Rust, by contrast, would be OK in the kernel applies at least as strongly to C++, because C++ can read kernel C headers, where Rust will need hand-maintained equivalents. (Some automation is possible, but not enough.) The FUD Linus flings about C++ applies equally to Rust. (Anybody who says Rust is less complicated does not know Rust well at all.)

But argument validity is not what carries the day: bad arguments tend to fail, but good arguments get pot luck. Ultimately, it comes down to biases of those with power to decide: C seems to them like a familiar quantity (full of risks, but favored risks), while Rust happens to be hot just now.

In three years' time, Rust could very well not be so hot, and a new new thing might take over its social role. Zig could conceivably be that thing. (Zig isn't "safe", by Rust's definition, but by then something else may be more important; anyway the lack of safety does not disqualify C.) The new hotness will necessarily already exist today, to be mature enough to consider then, but not necessarily one that immediately comes to mind. Being different from Rust could be, by then, among the new hotness's attractive qualities, much as percieved differences from C++ boost Rust in some milieus.

I know that many think that Rust is the be-all and end-all of programming languages, so much so that there's this effort to put Rust into Linux despite the requirement of nightly Rust versions and Rust still having inadequate support for various architectures. But the hype regarding Rust always seemed misguided to me, Rust is a language built upon the (interesting) idea of ensuring memory safety without a garbage collector, which is cool, but I get the feeling that most Rust fans forget that the actual goal is correctness, not memory safety.

On another note, using C++ in the Linux kernel could give a similar kind of improvement, but with much lesser costs than with Rust.

Rust is very cool and have no issue with it in the kernel tree but C++ would prevent so many bugs and eliminate so many lines of code. It's just ego.

Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in building ambitious system software.

Since you mention Qt, imagine writing all of Qt in x86 assembly, vs. C++. "There's not particular reason this isn't doable." C++ to Rust is a similar jump. No silver bullets; just leverage.

Cross-platform toolkits — especially those aiming to abstract over native UI/UX patterns — are an ambitious, if not Sisyphean domain. Qt was about the best we could do in the C++ era, but a new era has dawned.