I wonder if C codebases are going to have problems finding maintainers in the future. Postgres has commercial backing and inertia, but it seems like we are lacking a pipeline of (proficient) C developers.
It can feel daunting to today's web and application developers who are used to an opaque curtain between themselves and the underlying system architecture, but systems programmers using C++, Rust, etc already work behind that curtain (but with thicker gloves). They've often worked with C in the past, at least in education or experiment, and can ramp up on the footgun quirks with some intentional study when taking it up professionally.
There are arguments against picking C for some new systems projects, but -- outside a lack of systems programmers more broadly -- there's no pressing concern around finding maintainers for what already exists.
Yes, I think that will be the case. Obviously not a scientifically measured, by I think we're already seeing that average C skills for new contributors are lower than what they used to be - of course that might just be my slowly greying beard speaking. So far I think people just "learn on the job", but how much delta that bridge I am not sure.
I think eventually we'll have to make it easier to use some other language in parts of the system (e.g. in-core data type implementations). But realistically I think that's still a bit off.
That's definitely true. Just like everything else, actual experience matters and the C-share of public codebases (out of the total set) is less and less every year. So while someone may have studied the docs and overall language mechanics, he'd be less likely to have actually worked on a different C code base. Even less so for people who have worked on portable C software.
> I think eventually we'll have to make it easier to use some other language in parts of the system (e.g. in-core data type implementations). But realistically I think that's still a bit off.
There is an elegance to having the C structs directly match the data layout. But I suppose that it's only elegant if your mind has been wired from the start to think about byte alignment and word sizes. Coming from the world of interpreted languages with dynamic objects as bags of properties, I bet it's nowhere near as magical.
Doesn't this ability significantly depend on the system (and also becomes less relevant when you have variable length data)?
It's difficult to get into Postgres development, but that has little to do with C expertise. The hard part is having the right domain expertise. Building up general familiarity with the system just takes a long time.
I do wonder when even more C code bases are going to start seeing modules ripped out and replaced with Rust.
This is already happening with Linux, curl, and with C++ stuff like Chrome, many MS products, Amazon S3, etc, etc. The biggest explicit holdout I know of is OpenBSD, and that's because they're trying to keep the bootstrap / base install toolchain small.
While I'm sure I'd be able to pick up on the style of the project, it would take a lot of time. Large scale C looks completely different to C++. No RAII, no classes, virtual dispatch, smart pointers. Containers are completely different, templates/generics only via preprocessor.
I think C requires a lot more conventions and experience to get correct code than C++, and especially Rust.
I enjoy programming more when the above concepts are absent. RAII and smart pointers tend toward a fragmented and confused layout of a program's memory—there are much simpler ways!
The arena concept for managing your program's memory is more straightforward. It's easier to think about (not confused) and it becomes natural to have your memory laid out nice and orderly (not fragmented, which can be horrible for performance). See the recent article by Ryan Fleury:
https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...
I also think life is easier without classes or virtual dispatch. I value a sort of "mathematical elegance" in programming languages, and prefer to create programs from a small set of fundamental language primitives. Classes and virtual dispatch don't earn their keep in that set.
There's a growing trend in high level languages like Ruby/Elixir/node to use Rust + FFI to optimize specific hot code paths. Likewise, pgrx is a much more approachable path towards postgres extension development.
All of these development paths have always been available with C, but Rust has made them more accessible to a wider range of developers. I'd wager a non-trivial number of Rust developers don't feel comfortable in C.
https://img.ifunny.co/images/5dd3adca9d0da5310faa752ddd53565...
Or I might have revealed my ignorance about how much complicated C is.
"which is easier to learn" is basically an inherently subjective concept at this point, we as a field do not have an objective way to answer this question, except for extreme cases like the one I am drawing above. For any "real" language, it is much, much, much less clear-cut.
There aren't classes, generics, exceptions etc but that also means there isn't much to learn either.
I never said it was.
I specifically contrasted the two, saying that C is easier to build an application in than Brainfuck would be. Because it is. That means I think they're different, not the same.
Are they getting generally dumber for some reason?
I get that younger devs often don't have the low-level background older devs necessarily have, but all of the useful skills are learnable (and they have less bad things to unlearn, too). All good devs, of any age, have learned to learn what they need when they need it. I don't think anything has changed there.
I think the issue is more that key positions in these more prominent well established projects are usually filled and haven't been opening up.
Of course any competent programmer can pick up most languages. But projects written in a language that's in decline still have a harder time attracting developers (look at anything written in COBOL or Perl or TCL): it's less good for their CV than a more popular language, and the level of support in tooling and the library ecosystem tends to be worse, which means you spend more time working on the scaffolding and less time doing interesting work. And frankly C is already a language where you spend a lot of time on ceremony and bookkeeping and relatively little on the essence of the problem.
Some do have "eureka" moments and begin to understand many things about their current higher level language of choice. Others don't and struggle all along.
Most often than not, the 1rst category will have a much brighter career in programming than the 2nd one. And that is perfectly fine, as none can do everything.
So, i really think that C is my canary. Much like ancient greek and latin are in the academics. Except that C is actually still very useful by itself
An organisation worried about it can easily hire grads/juniors with a corresponding proficiency, and ensure that they still have that by the time they're seniors by employing them to work in C.