> But what is being overlooked, is the massive numerical dominance of C programmers
I roll to doubt. I haven’t seen C topping programming language popularity charts for a long, long time.
I used to interview software engineering candidates professionally. Candidates could pick any language they wanted for the interview. Python was chosen by about 70% of our interviewees. C was under 5%. (N=400 or so)
> I haven’t seen C topping programming language popularity charts
C is still highly ranked on many charts. C (as of July 2026) is ranked #2 on the TIOBE index. PYPL has C and C++ weirdly merged, the annoying C/C++, and that comes in as #3. The IEEE and Redmonk have C firmly in the top 10, using different methodologies. We also have to consider how many years back that C's run in the top 10 goes.
We have to also use context, as popularity can be a measure beyond simply job demand, relative to usage by students, hobbyists, open-source, and legacy. Furthermore, demand can be relative to location and country. Because it is less in your specific area or company, doesn't mean that's so in other areas or countries.
A job market specific survey: https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... They combine C and C++ together and it slides in at number 6. But together they only account for 5% of the job market. Totaling all such non-managed languages together is roughly 10% and that figure hasn't changed in decades. I'd bet that figure matches up with what consultancy firms that take on a wide variety of projects see. Needless to say, "massive numerical dominance" in relation to C is something that needs many qualifications to become true. Certainly there's a lot of C code out there, and C jobs, and in some niche domains it's very dominant. But there's just such a vast amount more of JavaScript, Java, and Python across more domains.
I'm sorry, but just mentioning TIOBE has killed any credibility you might have had. I mean, seriously, look at the list.
JavaScript at #6, when it should be at #1? Trailed by Visual Basic at #7? SQL (not a programming language) at #8 and R (have you ever seen an R job?) at #9. Then you have Rust just barely squeezing past Delphi? Followed by scratch???
Come on, this is not a serious source. Neither are the the rest really. Any popularity/usage list that doesn't have JS at first place is not serious.
Speaking for myself, I am never hired because I know C or C++, rather specific managed languages, however if there is the need to look under the runtime hood, or have bindings, like most Python libraries actually are, then suddenly it is welcome that I know C and C++ versus most folks on the team.
> suddenly it is welcome that I know C and C++ versus most folks on the team.
Yeah I know the feeling. But you don’t need Fil-C to learn C.
That said, with a GC, you could make some great tools & visualisations for learning C and understanding the memory layout of a running C program. That would be cool to see
to be fair, most programmers are at least a little bit polyglot, and if you know python and C and you're trying to solve an interview problem, python is gonna be the easier option 99% of the time, even if you're not that great at python compared to C.
Python is easier to write for interview questions. It generally doesn't scale well (in terms of size of team and codebase).
TBH C# is probably a good default for a lot of projects, from a safety and performance standpoint (rust's big performance win over GC/JIT languages is more in the memory consumption than throughput, counterintuitively). Fil-C probably still has a pretty good edge on python's performance, though.
> Fil-C probably still has a pretty good edge on python's performance, though.
Probably - but where are the benchmarks?
> Python […] generally doesn't scale well (in terms of size of team and codebase).
I’d argue neither does C. Everyone works around C’s lack of generics in their own way, so every large project becomes its own little world.
C’s biggest scalability problem is its lack of clear ownership semantics in APIs. If I call a function in your module which takes a Foo*, am I passing ownership? (So you’re responsible for freeing the object)? Do I need to retain the object while you use it? How long? Can I free the Foo when the function call returns? Or do you hold onto that reference until much later? Am I free to keep interacting with the Foo while you hold a reference? Can I do that from a separate thread, or is that unsafe? Every time I call a function in a medium to large C project (or in a library), I need to answer all these questions. Documentation is often unclear and the language doesn’t help at all. Mistakes lead to crashes, corruption and CVEs.
Real GC languages (Java, C#, JS, etc) solve this problem by just letting me write my code however I want. The object is freed when no more references are held. So I don’t even have to think about it. The cost is worse performance at runtime. Rust solves this with lifetimes and static analysis. You pay with complexity and slow compilation. But programs are fast and correct.
C - and by extension Fil-C - makes me solve this problem by hand. But you also pay a runtime performance cost to use a GC. This seems like the worst of all worlds.
Obviously people still write large programs in C. But I’d argue they manage that through grit and skill, in spite of C’s weak ownership semantics. Not because of it.
I roll to doubt. I haven’t seen C topping programming language popularity charts for a long, long time.
I used to interview software engineering candidates professionally. Candidates could pick any language they wanted for the interview. Python was chosen by about 70% of our interviewees. C was under 5%. (N=400 or so)