>guess any dev who can write Rust today is also a good C dev, ain't it?

Quite a number of Rust devs I've read about, have never been C devs. They came from dynamic languages or Java or similar, and stuck with Rust and learned it, as a more modern features-wise and less error-prone systems language than C.

I'm one such person.

I learned in C, it's the abstraction that exists in my mind for computers, but I'd never use it to actually write something, because of memory safety. I'd even been using Ada.

So, Rust was appealing in the ways C wasn't.

I would not want someone writing kernel code who can't understand what the rest of it is doing.

There is a difference between not understanding and not wanting to write C.

I'd be curious how C (and C++ for that matter) stacks up on some arbitrary "freshness" metric that measures some kind of statistic/statistics that indicate the average/median time it takes for the population of engineers to reach some particular level of "done"ness with a language.

I have no idea how you would measure it, but I'm assuming that C, VBScript, Perl, sed, AWK, bash, and Haskell (please don't hurt me I'm thinking about the code maintenance, time draining nightmare that is a real-world use case of mega-scaled purely functional codebases as opposed to a mixed dynamic with a purely functional core).

Curious what other languages would top the list. I'm going to assume also that some low-barrier entry scripting languages that are well designed, similar to Python, and languages that save the hypothetical, proverbial broken backs of their ancestors, like Rust, to be near the bottom of the list. I'm curious what that bottom part of the list would look like too, oddly enough. :D :))))

Modern C++ now has nearly all of Rust and other modern language features built in, some as flags. At the same time it has 30 years of ecosystem, cruft, and bad habits. It’s entirely possible to write performant, memory safe C++, even in a functional style. It’s a bazooka, and won’t stop you from firing at your feet, but it is also the right tool for big jobs.

The main problem with C++ is that it's too vast, it does everything and everyone has its very own choice of a subset of the language he should use.

The result is codebases hard to navigate, code hard to undestand with lots of clever code and unintuitive syntax.

Except... you know... the most important feature of Rust... the borrow checker.

The last time I checked, there were only nascent efforts to add the borrow checker to C++.

That's the main reason to implement in Rust (the others being syntactic sugar like match, ?, and, of course, the library ecosystem that learned from ~ C++17's mistakes).

It still lacks memory safety.

C is an amazing language. If you want to integrate into another language via FFI you basically have 0 other options.

That being said, it’s too easy to do something wrong in C. The desire to use Rust isn’t because C is stale, rather it’s too hard to write C correctly.

"amazing language"

ye ye, sure it is

uses physical pathes instead of logical namespaces for includes

average code base could be summed in such a way: everything is fucking "int" or its cousin - such a great tool for system modeling!

basic concepts as for $current_year are still non-trivial in C - like strings

when opening non-trivial codebase my VS Code goes crazy.

Maybe I do have high standards after using C# for years, but holy shit, writing Rust is 10 times better experience for me than using C.

My desire to write Rust is for both reasons. C tooling is awful, the language offers insufficient abstraction capabilities, and, finally, is unsafe.

Rust and C++ both have C FFI boundaries that the compiler can inline across. What more do you want?

Well for one, I don’t want to add another language to my tool chain. Many languages can compile C directly. For instance in Swift or Go you can add C source files directly to your project and have them compile as part of your Swift or Go build. You can’t do that with Rust or C++.

C is the lingua franca of the software development world.

Er....

I would also really love to read a statistics-based approach to all of modern software engineering. Like, does SOLID actually increase bugs? Is Agile more likely to slow things down? Etc.

This is the closest I’ve ever found: http://www.knosof.co.uk/ESEUR/

It strongly depends on the type of software being developed.

As the abstract of that book suggests (when referring to ego and bluster), 100% of the agile proponents I have encountered are incompetent. (This especially includes organizations that claim they are "agile").

Who said those people will be writing kernel code?

Rust for the Linux kernel is like 0.000001% of real life Rust use (which is not that big to begin with).

And it wouldn't be used the main kernel for the most part anyways, mostly (if not exclusively) kernel drivers.

This thread is about a kernel DRM driver written in Rust, writing any DRM driver requires a lot of knowledge about how the rest of the DRM subsystem and the kernel works.

The subthread though is about whether "any dev who can write Rust today is also a good C dev, ain't it?", not about kernel drivers...

I understand C just fine, hacked on kernels before, could easily write “safe C”.

1. I just don’t enjoy C. At this point after writing so much code “for profit” it’s no longer a hobby in itself. If I’m writing code “for purpose” I need to enjoy it!

2. While I trust myself just enough to write some C, I don’t trust everyone else to retain a strong foundation for whatever I’m building on top.

3. C has carried the Linux kernel for its first 40 years. Having used Rust it’s clear the future (while maybe not Rust) is definitely not C. I want to make a contribution that will endure the next 40 years of Linux.

That's a pretty naive statement. No kernel dev knows what the rest of it is doing. Because the rest is a tens of millions of lines code base.

>guess any dev who can write Rust today is also a good C dev,

I'm sure they have the potential, but they might not want to learn/use C.

I'd certainly be much more likely to look at kernel dev if I can use rust than if I have to use C.

my point was more that given rust is so young people proficient in it have probably also experience in more classic low level languages

But that doesn't mean they want to deal with C code in their free time.

I used to write bare-metal C for my day job. It's pretty hard to get everything right when the language has so many sharp edges. I wouldn't want to use C for a bigger project (e.g. the kernel, drivers, a gui app) but I'd quite happily use Rust because the compiler will yell at me if I do something stupid

Not OP but I'm waiting for Rust support to be finished before I look at kernel development. Don't have any interest in writing C.

Honestly this is a bit of a fantasy. If you love Rust and hate C, and haven't looked into kernel development before ... it's a whole different ball-game than user-space Rust. With a variety of real-world hardware, and the complexity of modern CPUs, and demands of a variety of complex user-space software, you just don't have the "guarantees" and conveniences you want, at this layer. The hardware does what it does and you just have to deal with it. User-space C code can be way easier to reason about. For a small taste see https://lkml.org/lkml/2022/9/19/1105

Yes, but dealing with low-level stuff in Rust is going to be easier than doing that in C. See for example the blog post by Asahi Lina talking about how it was easier to program the M1 GPU driver in Rust than it would have been in C.

Even in best case scenario Rust code will be confined to individual subsystems and drivers for a very long time. And even in these subsystems you will probably still have to interact with a lot of C code from shared data-structures in other subsystems.

Most of Linux kernel is drivers, so if new drivers can be written in Rust, it's a huge win in safety for the whole world.

No, it's just not true. Just look at Google's recent Android statistics as a validation.

I'm not paid to contribute to the Linux kernel, albeit you may get some reputation benefits out of it. It's mostly a hobby: if it sounds fun, I might do it - otherwise no chance in hell.

Contributing to a C kernel sounds like a thankless job with crappy tooling and high potential for errors - and frankly just brings back horrible memories (ahhh, the segfaults).

Developing in Rust on the contrary is quite enjoyable and I'm definitely more inclined to contribute something.

Not really. C is a simple but dangerous language where the compiler doesn't do much for you, Rust is the opposite. It's like chainsaw juggling vs bridge.

Life is too short to desire writing in C and/C++.