> If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person.

You are taking this the wrong way around. It's not about people contributing to $PROJECT because it uses $COOL_TECH, it's about people being turned off from contributing to $PROJECT because of $MEH_TECH.

If Linux was written entirely in assembly, we'd be having the same argument about the introduction of C.

Ironically UNIX was indeed written in Assembly, and C only came into the picture with V4.

Also BCPL, the basis for B intepreter, was originally designed to Bootstrap CPL, not really as a daily use language.

As a potential alternative thought process I would add that kernel development sort of uses their own flavor of C that you also have to learn. While in case of a language with better abstraction powers, you can actually read a function and knowing only the language but not the project, could potentially contribute — as opposed to C, where I have to know this cryptic macro, and that by convention this and that struct has to be embedded x bytes into another struct so that it can be used with the linked list utilities made.

Also, simply by having god damn namespaces more readable names could be used at no downside.

> From my point of view what counts is actual kernel development. If you are going to develop kernel because it uses cool new language but you would not if it was still C, you are probably not the right person.

Why's that? C is a tedious language that makes you do so much manual bookkeeping, I don't think I'd ever write it again (if I needed C for some reason I'd write a program to generate it for me rather than doing it myself). I think any decent developer would be put off by C to some extent. Sure, the people who really want to make a kernel may put up with it, but an arbitrary enthusiasm barrier is not the way to attract good contributors.

> I think any decent developer would be put off by C to some extent.

Any decent developer would be put off by any language to some extent.

Personally, I'm more put off by Rust than C (they put me off for different reasons). Currently, the one puts me off the least is Zig, but it still has many details that I don't like.

On the other hand C is simple language, there are no discussions about how to do something in C between people who know C.

C is tedious but kernel programming isn't about spewing vast amount of code anyway. It is more important to be able to read it, understand it and ascertain it is correct. This is one of main reasons for why C++ is not there.

> C is simple language

Except for, you know, all that Undefined Behavior stuff, which makes it practically impossible to write correct programs even for very skilled developers, or the lack of abstractions, which makes it hard to safely re-use advanced data structures.

"C is a simplistic language" would be more accurate.

C encourages simplicity.

Code is either clear and simple, or extremely obscure and safe, or kinda in between is complicated but not complicated enough such that its not safe.

"Simplicate and add lightness" aerospace mentality people like C.

At some point any project expected to do ever more complicated tasks, like a kernel, will be unable to use simple C and will have to take the hit of a more complicated language.

Simple is good when matched to simple tasks; my microwave oven or TV should ideally never data network with the external world and never malloc memory and never do string processing. C makes an amazing toaster or car automatic transmission controller.

C is simple only as a pseudocode language, i.e. to reason about the happy flow. As soon as you start adding corner cases and error handling, all your happy flow code now gets obscured by numerous ifs, switches, and ($deity forbid) goto statements. Then, add pointers masquerading as output parameters, pointers masquerading as arrays, and pointers masquerading as pointers and your language isn't so simple anymore.

Flintlock pistols are simple, do you think they are more reliable or easier to use than an AK-47?

Which one would you rather defend yourself with?

C++ is definitly there, just not on Linux.

>"I think any decent developer would be put off by C to some extent."

Call me indecent. I use C for firmware development running on small microcontrollers and consider it perfect for this particular task. Not put off by C for this task at all.

It is a little bit bogus, I did not say that I stand by it or that I think that this is the WAY. I'm not even a Linux developer or a kernel dev, though I've done embedded programming at the beginning of my career. Just that if we won't take risks, we will never know whether the approach of Rust or Zig or just plain-old C would prove to be THE approach to systems programming. Besides fragmentation, how else can you harm what we already have? I believe the ecosystems fix themselves, if you offer to the developer three choices (in our case C, Zig, Rust), we will see how things pan out and we will have a clearer picture. Java did not become the language of Fortune 500 companies out of sheer luck, people simply chose it more often than its counterparts because the feedback was positive. I expect the same in systems programming.

a couple of things:

1. rust is easier to read than c/c++

2. The toolchain is llvm based and much nicer to use than c/c++. Hell your build scripts are also rust

3. Given the choice to develop in c or rust I would choose rust

4. In my own experience I have found rust to be simpler to Deal with correctness than c/c++

(I have been both a rust and c++ developer)

> 1. rust is easier to read than c/c++

Rust may or may not be easier to read than C++, depends on your experience.

But it is not true it is easier to read than C. C is objectively much smaller, simpler language than Rust.

> 4. In my own experience I have found rust to be simpler to Deal with correctness than c/c++

That is the whole point of Rust. And also to do this with minimum runtime overhead.

C is a smaller language on some axes. That's not necessarily a good thing.

Looking at the following function definition, can you figure out how to use it safely?

    int foo(char* text, char* out,
            char* s, char* x);

If you were to have the same signature in Rust, it would look more like the following:

    fn foo(
        text: String,
        out &mut String,
        s: &str,
        x: &mut str,
    ) -> i32;

Now it is clearer that foo is responsible for getting rid of the allocation corresponding to text, which is on the heap. out can be modified and potentially reallocated. s is read only and it won't be deallocated by foo. x might be mutated in-place by foo, but it won't be deallocated.

Having a more "complex" way to represent in the typesystem something that C only bothers to call "a pointer" makes things better: safer, easier to skim, explore and understand an API, and allows the compiler to catch API misuses.

Being a smaller simpler language doesn't make it easier to read or write. Go is an even "simpler" language than C, but you quickly suffer from boilerplate-blindness when reviewing it. Being able to write good abstractions can make a huge difference. Having lifetimes, or the use of the semantically-correct integer type checked by the compiler reduces the cognitive load on the writer and reviewer.

>"is objectively much smaller, simpler language than Rust."

Brainfuck is an even smaller, simpler language, it has only 4 characters!

Yep that is my experience. C++ sucks. Thinking in rust and getting your ideas out is much much much easier. C is portable assembly, I prefer a language that protects me from footguns. I have better things to think about.

It's even worse, C is “portable” PDP-11 assembly. It has been a few decades that a C program is only distantly related to the assembly the compiler will generate.

On the Rust vs C++ scenario, try the next level with Rust:

- GUI code

- Generic datastructures crates coupled with lifetimes, macros and attributes