C

Created 04.09.2022 Updated 03.03.2026

I learned C around 1998, mostly by trying to fix bugs in open-source software. I had some experience in BASIC, Turbo Pascal, x86 MASM and Visual Basic at that time. C was the main programming language in the UNIX world at that time; all major open-source software in those days was written in C. Most of these projects had very high discipline in maintaining the codebase, but bugs were still common. And they remain common to these days.

Between 2001 and 2013, I dealt with a lot of commercially written source code in C, the oldest parts reaching 25 years of age. I strongly believed then that I’ve faced most possible scenarios where things in source code can go wrong, leading to days of ripping hair out of (mostly managers’) heads. Scenarios where fixing one bug collapsed a working application in some corner case were our daily bread. Even if you could find remnants of brilliant architectural ideas from the beginning of these projects, these patterns weren’t kept and maintained, over time fading into some spaghettized monstrosities.

When I started using C++ more, a picture was painted in my head, where it was clear that the burden and cost of maintaining quality are much lower in C++ than in C. Then, when I started to enjoy Rust, it became more obvious that in 2021, choosing C as a programming language for a new project is practically a prolonged suicide. There are absolute masters of writing C code out there, most contributing to the Linux Kernel; however, a software project in C is as good as a worst and least skilled programmer within the team. Companies are still maintaining C code, not without reason, have spent millions of dollars on static analysers in the hope of catching as many bugs as technically possible, but still have huge security ofholes in their applications.

It’s quite common among many C advocates to repeat that this language is good and simple, quite often citing the success of the Linux Kernel… forgetting that no other software project can afford the scrutiny of so many skilled eyes reviewing their code in the day-to-day job. This reality cannot be ignored anymore.

I’ve decided to refuse to work in C as my main programming language, not because my skills are poor, but because I can’t trust that anyone else can deliver a good enough quality in a fast-paced environment of commercial software engineering. Poor buggy results are too stressful, especially when life could be much easier if the right tools were selected for the job.