LKML discusses merging Rust access to filesystem APIs

> C is incredibly easy to grok.

what does this mean, though? writing good, secure C is so hard that literally no one can do it at scale. not Linus, not Theo, not even djb.

why do you find "learning enough to write bad code isn't very hard" to be valuable?

I'm not even really convinced that C is that useful as an approximation of "how computers work" anymore - caches and NUMA and speculative execution and mmap and large numbers of varying ability cpu cores and asynchronous code make C more of an approximation of "how the PDP worked in the 1970s" (with an abstraction layer that is an endless rolling nightmare of critical security issues), which I guess is a bit useful, but not as the thing we base the world on. and a C with array bounds checking and length-prefix strings would still have a shitty type system and no meta programming and not even an iteration protocol (or ability to add a nice one).

> Remind me again why we can't use Pascal?

I would guess it's because Unix-alikes (and for a while Windows, though I guess it had less C and more C++ earlier) ate the world and using the language (almost all of) the OS was written in had huge network effects.

I'm sure there are lots and lots of options in the design space here that would have been viable, but for better or worse this is the one we got. I dunno why Pascal didn't happen (but large portions of developers scoffing at the language shouldn't be discounted: this is as much a social consenus building exercise as a purely technical one), but for the "simpler C" versus Rust question it seems to me that there's some kind of local optimum around C, in the sense that the people interested in safety wanted more than is possible with small changes to C and the people who wanted to keep C weren't sufficiently motivated to actually make the changes (Regehr touches on this in the first part of the article, getting any kind of consensus on what Friendly C should actually be turned out to be very hard).

If you liked Pascal and like Python and prioritize the things you mentioned and are considering languages as young/rough as Zig not directly compatible with C but with easy declare-and-go FFIs, then Nim https://nim-lang.org/ may really be the language you are looking for.

While inheritance/objects (and even multi-method dynamic dispatch) do exist in the language, they are not widely relied upon in the stdlib or ecosystem in general. Nim has much more lisp-like metaprogramming / syntax macros than C++ (but its richness of syntax for expressiveness compared to sexp's makes such metaprogramming quite a bit more work). Another way to start to describe it might be a far more terse, less factored Ada with more modern lexical aesthetics.

While I know of no specific Linux kernel module-in-Nim project, since Nim can compile to C, it should require no hand holding|permission-slip for Linux integration, although I'm sure it could be made "nicer", as can anything. (People are also writing a few OS kernels in Nim.)

> C is incredibly easy to grok

No it really isn't. Newbies struggle with pointers all the time, before they even get to the question of pointer lifetime and what is and what is not safe pointer arithmetic.

> "C with X"

I think the most interesting areas here are Zig and D, although I'm not too familiar with them myself.

Really what we want is an end to "can't spell CVE without C": a language which makes it as difficult as possible to write software which can be compromised remotely.

> I think Rust is an improvement over C, but I also think it's unfortunate that there's nothing which is similar to C, but safer.

Modula-2 exists since 1978, the only downside versus C in terms of safety, is the use after free still being an issue, everything else was already covered.

Modula-2 was inspired by Mesa, created by Xerox PARC as they desired a secure systems programing to move away from BCPL.

In many regards, Zig is Modula-2 with a syntax more appealing to C minded folks.

The thing that is provoking the switch is really in the "disruptive 10x better" areas, which Rust does offer around certain aspects of resource management. Zig is aligned around a different axis of "better", that axis being making a small-core, bootstrapping, C-compatible system. For the kernel project, the build-and-bootstrap problems were solved in an internal sense eons ago - there is a documented process. The process might not be particularly pretty or elegant, but switching won't make it 10x better.

On the other hand, small apps that need to "do things with bytes" and want to link to a bunch of dependencies have an appealing answer in Zig because it proposes solving their problem in systematic fashion.

I like Pascal, but the 10x isn't there: it could probably be 2-3x better than C for a lot of things, in the Dephi or FPC variants. It has the bits that people will "write C in C++" for, with much less WTF.

Literally the best programmers and biggest companies in the world have given up on C because no one can actually write it securely. I promise, you're not as good at C as you've convinced yourself.

Trust me, I've read this opinion from a certain group before. Whose compositor segfaults on me weekly.

And Rust has neither objects nor inheritance, so.

Zig has the especially interesting feature that it can compile C code.

I admit I don't know enough about kernel development, but from general experience one common example is resource cleanup.

Say, you have several resources that must be cleaned up in certain order. In C, you would just call the appropriate free functions. When abstracting over that with rust, you have to make an annoying choice:

Do what's in C, don't implement automatic Drop, but mark your functions unsafe. You get leanest zero-cost implementation, it is straightforward to understand, but needs additional maintenance care to prevent bugs.

Wrap resources in unsafe structs that have automatic drop (when goes out of scope). IMO this is a terrible choice, because the maintainer suddenly has to know about which structures have this unsafe cleanup going on. Simple scopes suddenly matter, order of items suddenly matter, it's a mess.

Use reference-counting wrappers to track usage and drop the items when they are no longer in use. Most libraries do this, but it's no longer the leanest possible API.

There might be another choice, to achieve both zero-cost execution and correct cleanup using metaprogramming, be it macros, generics, or both. That's exactly what I fear the most.