Hacker News Reader

Comment by Keyframe | Hacker News Reader

In my core I'm the same. C is my language and served me well for decades. There's nothing inherently major wrong with it until you reach one of the two (or both). Working in a group of people on a C codebase tends to introduce pain on multiple levels unlike some other languages (yes, including C++). The other is that anything takes a long-ass time to do compared to modern alternatives, which might also be an issue if you're developing a game; Especially if you're developing a game. Having said that, I can't disagree since as I said, I'm also inclined towards it's siren call of simplicity.

View on HN

Why do you think working with a group of people on a C codebase introduces pain unlike other languages? Working with a group of people always causes pain, but I found the pain much less severe for C than for C++.

In my mind using a simpler language should be less painful given there is less to argue about given syntax and versions etc. Take c# for example you have multiple ways to do the same sort of things.

Your question also hides an answer. You don't often get to chose a group of people you work with, and unlike projects that self-attract and self-distill ideal profile (like linux mentioned in sister comment), you're left with people usually not used to ye olde C idioms. With C++ it's a bit easier since it is more widespread and supports some of the idioms people get used through schools and other projects. Of course, projects (should) always dictate a certain discipline by different mechanisms, but if certain way of thinking isn't ingrained then it introduces just that much more pain to the communication layer between people.

I would argue that is is much harder to find a group of C++ programmers who write a coherent style of C++. In C there is not nearly as much to decide. Note also that I am speaking from experience with both.

C relies on the programmer to understand the lifetime of every object in the program, which is global structure. When the programmer is multiple people, it's easy to get out of sync. unique_ptr from C++ solves 90% of this.

Ever use a leak detector? Even my graphics engines (with shared resources) uses a leak detector in debug mode. The monent you forget to release a resource, assertion at program termination.

Leaks are trapped with tooling, and all you need is one dev in the team to be diligant to run valgrind or visual leak detector or similar.

We run valgrind and asan as part of the CI, so it is checked before every merge and no developer has to be particularly diligent. But it is also not something that triggers a lot.

Do you think the best way to avoid bugs is to thoroughly test your code, or does understanding the code while you write it also help?

It depends on what you're building with the language too.

For eg. In very embedded contexts where we were not using any big data structures like struct of strings, not doing any memory allocations etc... C might be easier to reason about than C++. (No hidden code paths). Just allocate something on the stack, pass the pointer to a function to do the computation, done.

In any desktop apis (gui, web servers etc..), where you deal with collections of objects, need to spin up thread pools and rely on results from the future etc... The standard library data structures (vectors, maps etc...) alone makes C++ code a lot more easy to read and review than C. When raw pointers are forbidden, Ownership of memory becomes very clear. Granted my opinion of desktop development comes mostly from very few libraries (Qt vs. Gtk, gstreamer's C API vs. C++ wrapper, http libraries etc...), but there are some problem domains for which C is just insufficient.

> Having said that, I can't disagree since as I said, I'm also inclined towards

Say more with less.

>Working in a group of people on a C codebase tends to introduce pain on multiple levels unlike some other languages

linux attracted 2,134 developers in 2025

that kinda weakens your argument a little bit

Maybe (and I like C, for the record), but it doesn't follow necessarily. It's possible most of those devs were attracted by "working on linux," and are putting up with the pain of collaborative C. I know there's a movement pushing for more Rust.

I think the popularity of Rust for Linux is also in part a reflection of internal discontent with poorly documented and sometimes straight up poorly understood kernel internal APIs.

When a developer asks Can I Fizzle this Doodad? C is comfortable with the answer being "It'll definitely compile but whether it would work is complicated - ask the expert on Fizzling and the Doodad expert, and hope they give the same answer" but Rust wants the answer to be "Yes" or "No" or at the very least, "Here is some actual text explaining when that's fine"

Sometimes it really is hard work to figure this out but for a project as big as Linux even in those cases it's often worth doing that hard work, because you unlock something valuable for every non-expert contributor and Linux has a lot of those.

It proves the argument as an outlier. I explained in another comment. You often don't have the luxury of selecting the group of people you work with and more often than not, especially these days, people aren't used to (C) way of thinking which just introduces more noise to the communication between people.

If Linus started his OS project in 2026, he might have chosen Zig instead of C.

Reply on news.ycombinator.com