I write mostly like I would in C, but use C++ features as needed. It ends up looking similar to Rust if you squint. All these "I write games in C" people complain about C++ features, and then end up reimplementing virtual interfaces manually with struct headers or massive switch statements, just to feel better about themselves. Writing games in C is not harder, you just have to implement modern language features by hand.
Complaining about a language having features you don't want is silly. C++ doesn't take longer to compile if you don't abuse templates.
> Complaining about a language having features you don't want is silly.
It might be silly if you're working on your own. Software that delivers a lot of value is usually developed and evolved not only by team, but by a team with changing members and changing leadership over the project's lifetime. The features used will be the union of all features used over the years, and while it's easy for team leads to allow the use of more features than their predecessors, it's quite hard to reduce them.
Also, you may be forced to use language features you don't want if they're used by libraries whose functionality you do want. For example, when doing low-level programming, I don't like implicit calls that I can't clearly see on the page (e.g. destructors or overloaded operators). But if libraries I want use them, then I'll have those implicit calls. But if the language doesn't have those features, libraries obviously won't use them.
> C++ doesn't take longer to compile if you don't abuse templates.
It actually does though, unless you also drop C++ stdlib usage completely (have you looked at how many lines of code just <vector> alone pulls into each source file? - it's upward of 20kloc and growing with each new C++ version).
And at that point you get into discussions with various C++ camps about why you don't use the C++ stdlib and instead prefer to reinvent the wheel (and this friction with other C++ coders is the main problem of carving out your own subset - it works ok in complete isolation, but software development work hardly happens in splendid isolation and even then you'd might to want to use C++ libraries written by other people from time to time...)
And once you've been dragged into such C++-subset-discussion month after month, year after year, at that point it is much less exhausting to just write plain C. And the C community (if it can be called that) seems to be much less concerned about coding style dogma and generally a nicer bunch to interact with.
FWIW, I switched around 2017 and each time I have to interact with a C++ library for lack of alternatives it's usually not a pleasant experience (with the notable exception of Dear ImGui - but even there I started to prefer the C bindings so that I don't need to strictly separate the UI code from the rest of the code base, which sometimes makes sense, but often not, especially with an immediate mode UI framework).
> then end up reimplementing virtual interfaces manually
C++ dynamic dispatch (your "virtual interfaces") is achieved by welding a vtable onto every type and providing a pointer to that vtable for instances of the type. If in 90% of your code you deal with specific types like Goose or Swan or Duck or Seagull, and only 10% needs to work with the broad Bird category well, too bad, every Goose, Swan, Duck and Seagull carries around that vtable pointer even if it goes nowhere near that 10% of the system. This way your Bird code "just works" in C++.
That's not the only way to crack this nut. Idiomatic Rust approach uses vtables only in the Bird code, elsewhere they don't exist, and thus don't take up space in a Duck or whatever that's always a Duck, but in exchange now you're spending more time thinking, because by default there aren't any vtables and so dynamic dispatch isn't possible at all.
So while that C programmer has to implement features by hand, they are at least able to specifically implement the feature they wanted, not whatever was easiest for Bjarne Stroustrup last century.
> C++ doesn't take longer to compile if you don't abuse templates.
Surprisingly, this is not true. I've written a C++ file only to realize at the end that I did not use any C++ features. Renaming the file to .c halved the compilation time.
I measured once and to my surprise templates aren't (directly) the reason for long compile times. It's function bodies in headers, and obviously templates are in headers and they call other templated functions/classes which explodes code generation and time. But if it's only a few lines and doesn't call other templated functions it's likely fine. I wrote about it here https://bolinlang.com/wheres-my-compile-time
After writing that, I wrote my own standard library (it has data structs like vector, hashmap and sets; slices, strings, rng, print, some io functions, and more) which uses a lot of templates, and it compiles in <200ms on both clang and gcc. Many standard library headers take much longer to compile than that. It's not a terrible idea to have your own standard lib if you need quick compile times.
I’ve seen this play out a lot. People say they “write games in C” and then quietly rebuild half of C++ anyway with vtables in structs or giant switch statements, just without the compiler helping. That’s fine if it makes you happier, but it’s not obviously simpler or safer. Also, C++ compile times are mostly a self-inflicted wound via templates and metaprogramming, not some inherent tax you pay for having virtual functions.
C++ reimplements a lot of the things we do in C with function pointers, while hiding what's actually happening behind topheavy syntax that implies a 1990s object oriented paradigm that's dead now.
Of course people do" virtual functions" in C, but I think this is not an argument despite C.
I noticed that making virtual in C++ is sooo easy that people start abusing it. This making reading/understanding/debugging code much harder (especially if they mess this up with templates).
And here C is a way - it allow but complicates "virtual". So, you will think twice before using it
> Complaining about a language having features you don't want is silly.
If your criteria for a good language is "how many features does it have", then sure, C++ wins. OTOH, if you criteria is "How many footguns does the language have" then C++ loses to almost every other mainstream language, which includes C.
Yeah, you could argue that choosing C is just choosing a particular subset of C++.
The main difference from choosing a different subset, e.g. “Google C++” (i.e. writing C++ according to the Google style guide), is that the compiler enforces that you stick to the subset.
For every person who says on the internet that you can just use a C++ subset, there's another who insists that C is the bad C++ subset. So compiling C code with a C++ compiler promotes your code from "good C code" to "bad C++ code" (most C code isn't "exception safe," for example).
It's arguably irrational to evaluate a language based on this, but you can think of "this code could be better" as a sort of mild distraction. C++ is chock full of this kind of distraction.
I feel like, for me, it’s that I am more familiar with writing in C and switching to C++ seems rather difficult. So, sure I am reimplementing features that already exist in anoter language, it just so happens in this case is C++. Why not use python if you want to avoid reimplementing the wheel as much as possible. And sure python is not suited for game development but I just wanted to make a point with it. I think in the end ising a language you are most familiar with results in the most amount of enjoyable coding.
Exactly, not even do you need to religiously need stick to your subset, separate modules can be using supetsets that import useful libraries and if they're used for code that is seldomly changed (such as model importers) then the longer compile time will only matter for rebuilds and not quick tests.
It's possible to use only a subset of the language. You could write a Java program without classes if you really wanted to. Just put the whole thing in main().
A lot of smart people pick and choose what they want from the language, just like religion, they keep the good parts and discard the bad.
I always liked C. I enjoyed how brutal it is, except the preprocessor.
This is why zig is a godsend. It is actually simpler than C while being more precise than C!
For example zig can distinguish between a pointer to a single element vs a pointer to an array of unknown length. Where as in c abi, it is all T*
When importing a c lib, you can make it more ergonomic to use than c itself.
Being able to easily import c lib is especially important to game dev, as practically all so called c++ libs also export a c header as they know how important it is.
I totally resonate with the author of the post. My main requirement to enjoy a language deeply is often simplicity, so I love languages like, C, Golang, Odin and Zig.
That said, I also acknowledge that often times I need to solve problems that can benefit from a language that embraces what I call necessary complexity, but do it in elegant ways. Whenever I need to prioritise code correctness, especially memory and concurrency safety, using a mostly functional pattern instead of OOP, but without going as extreme as say Haskell, I unquestionably choose Rust, my favourite complex language. I often work with network code that is highly concurrent, must be as correct as possible and benefits from good performance, so then again, Rust feels natural here.
On the other hand, I love coding simple indie games and for that particular case, I like a simple and performant language using an imperative, non-OOP style. In my opinion C, and in particular Odin more recently are quite a good fit. If Jonathan happens to be reading this comment, since he mentioned Golang, I would suggest him Odin as perhaps the best of both worlds between C and Golang. It has all the simplicity of Golang, but without a garbage collector, plus it is quite easy to code a game using Raylib.
> I would suggest him Odin as perhaps the best of both worlds between C and Golang.
It's interesting to me that you say this, because it's the exact way that I describe Zig to people. Especially with the new std.Io async / concurrency changes. Do you feel Odin fits the space between Go and C better than Zig? Or just differently, and they both share the same space?
The first capture of the page on Internet Archive Wayback Machine is from January 9th, 2016. So it’s at least that old.
Also here is a snapshot of the main page of his website from that time, which has screenshots of his games and thereby provides context into what kind of games he had made and published when the blog post was written.
I've been working religiously for like 2 years on the jedi academy codebase which is c & c++. It's Ravensofts variant of the idtech3 engine and it's insane how fragile the games combat is to precision and timing changes, I can't get away with adding much without destroying the lightsaber combat qualities. There are certain spots where I can't even add an incrementing i++ counter lmao it presents just enough of a slowdown or shifts something around that I haven't been able to track down that bleeds into the rest of the gameplay, but I am also sticking with the ancient compilers from 22 years ago so as to preserve the fpu characteristics of the game. There are some modern attempts at using this codebase with modern tooling but they've kind of bastardized/refactored all of it and it just feels different/unbalanced wrong. idtech3 is such an incredibly foray into c it's really something else and carmack and team really sent it back in the day.
Literally thousands of games have been written in C, and all graphics APIs (OpenGL, Vulkan, DX) are C APIs, so it isn't weird at all. All major game engines are also written in C/C++.
DirectX is C++ (technically a set of COM interfaces) and most game engines are also C++.
Unlike, say, Linux programming where C is the standard, almost all games have been written exclusively in C++ for a long time now, probably three decades.
Khronos APIs are C, DirectX is C++ exposed via COM or WinRT, Metal is Objective-C with C++ for shaders and Swift bindings, on Nintendo and PlayStation depends on which console generation you talk about.
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.
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++.
When people say "nobody .." or "everybody .." they often - maybe even usually - do not literally mean 100.000000% of people. You are an outlier. He is still correct to say "nobody does this".
> I like Go a lot. In many ways it is C revisited, taking into account what has be learnt in the long years since it was released. I would like to use it, but there are big roadblocks that prevent me. The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do.
I'm no Go fan, to be clear, but GC isn't the problem with Go. It has a pretty decent GC with sub-millisecond pause times. People who complain about GC pauses while extolling the virtues of manual memory management are running on a set of prejudices from 1999 and are badly in need of a mental firmware update.
The performance gains from bit-level control over memory come from managing the layout to ensure cache locality and do things like SIMD - and nowadays even GPU kernel offload. Enormous performance gains.
I agree that it really isn't about garbage collection pauses, but I haven't heard people focusing on "eliminating gc pause" when they talk about low level languages, but they spend a lot of time talking about SIMD, GPU kernels, and cache misses. If Go could add these features, it would be a performance monster.
I did read the whole article thinking "who is he, his name reminds me something, but why isn't he providing game names?" and so on. Then I clicked on "back to main site". Revelation. A lot of his games are jewels. I have a special thing/relation with Sportsfriends. So many hours of fun while playing with my son.
Noble quest, but without operator overloading when dealing with Matrix*Vector you end up with an unreadable mess for physics, skeletal animation etc. There is a reason professional game dev is still 90% C++. (Funny enough, amateur gamedev is C# these days, students use what they learn at uni).
I like C. You can take away all memory management (yes, including some of the unsafe glibc calls that have hidden memory management) and everything can be so smooth and clean. Since rules like MISRA require up-front allocation - if any is in use - this can be tightly controlled.
Very useful if you don't want (or need) surprises anywhere. Or if you want all the surprises (exceptions, errors, etc) all better tied to the hardware that provides such.
It's also fairly easy to write unit tests for everything.
C has very low entry level, providing that you have some knowledge about memory management. When, as a Java developer, I had to quickly deliver some exchange connector using given .h and .so, I chose C, because C++ had too high entry level. If C is a sharp knife, C++ is a rotating pell post full of sharp knives. You can cut yourself even if you think you're safe.
But I find string management in C awful and would like to borrow it from C++. Only the string management
I'm pulling apart and rewriting so far a little in C a personal fork of OpenTTD 12.2. I began on it a few years ago for the first time for the heck of it after patching for realtime, began again while adding features I wanted until I hit a bad enough snag, and now began again by first extracting most used functions and profiling with Valgrind inbetween.
Things I noticed are inconsistent coding styles, overly complex processes, unused(!) functions, inefficient data use, nothing surprising with a project worked on by various people in their spare time and their own ideas on how to code. And this isn't even talking about later versions. To me it's an example of how unrestricted access to bling features causes a mess.
Eventually I want it converted to C (C23), split apart in seperate functions with a decent source code organisation, and simplified processes to make it easier to understand what's going on and extend fuctionality. For this I need it simplified as possible and weed out the layer of complexity caused by C++ first. Going to take plenty of time, but I'm still having fun doing it (most of the time anyway :-p ).
I'm not advocating anything, but it's satifying to me to bring clarity to code and see small improvements to performance during the process at the same time. It also gave me an opportunity to develop a unique syntax style that visualises parts of the code better for me.
This is great! This so rare that people remove the complexity again that has accumulated over the years. Most of the programming world is just accumulating entropy and then people give up and start fresh at some point, which is just sad.
As a hardcore C programmer and zealot myself... How in the hell can you be productive like that? C is a systems programming language, not an application programming language, let alone relevant to the levels of abstraction you'd want in game development.
That said, "I am dead" is a very real video game indeed... and his arguments are very sound. I also can't stand C++. I disagree with him on Java though. The core language of Java is actually super simple, like C.
I think the productivity question hinges on what you count as the language versus the ecosystem. Very few nontrivial games are written in "just C". They are written in C plus a large pile of bespoke libraries, code generators, asset pipelines, and domain-specific conventions. At that point C is basically a portable assembly language with a decent macro system, and the abstraction lives outside the language. That can work if you have strong architectural discipline and are willing to pay the upfront cost. Most teams are not.
I agree on C++ being the worst of both worlds for many people. You get abstraction, but also an enormous semantic surface area and footguns everywhere. Java is interesting because the core language is indeed small and boring in a good way, much closer to C than people admit. The productivity gains mostly come from the standard library, GC, and tooling rather than clever language features. For games, the real disagreement is usually about who controls allocation, lifetime, and performance cliffs, not syntax.
You have to try it. You can write anything you want in C. Or assembler. It's hardly going to be very productive but... productivity is greater than zero, and the more you try the better you get. Rollercoaster Tycoon was written by hand in assembly, as were all NES and SNES games including ones like Earthbound and A Link to the Past — and SNES assembly isn't nearly as nice as x64.
Yes, having built-in generic containers and algorithms is the part that keeps me favoring C++. Bespoke versions of these can always be written in C (and work fine) but C++ makes it much easier and saves time. Lambdas and function objects are also useful.
Time escapes me before I get a chance to type Hello World. Working in front of a screen eight hours a day leaves me exhausted that the least things I want to do is code more on my day off.
Although wanting to dive in to WASM has been a priority and checking Odin for wasm their 3D model example is super cool.
May just have to take a poke. TCL for web frontend; Erlang for DB and potentially Odin for wasm? This could be a cool mix.
Did a bit of game dev in Odin last year and it was a wonderful experience. It's very much game dev oriented and comes batteries included with many useful libraries. And the built in vector stuff is very helpful there too.
Then Watcom C/C++ made it quite easy to use C++ for game development on PCs, PlayStation 2 introduced support for C++, quickly followed up by XBox and Nintendo, and that was it.
I also use C, for games and other stuff. However, for many games it can be useful to have a game engine, which is written in C (and I might write it by myself) but other parts will be written in the game engine. I also sometimes program games on DOS, and will use BASIC or Pascal. You will then not need to have too many dependencies; if it is a DOS program then the executable file should just work (with emulation if necessary) without the mess that is common on modern computers.
Haxe is a great language but it feels like the ecosystem has been stagnant for 10 years. No Vulkan bindings, no SDL3, still trying to be a web language that happens to compile to native code instead of getting with the times and going fully native + maybe wasm. Part of me wants to write my own bindings to SDL3 in Haxe but it's far easier to just use Odin these days.
I want to write general apps in C. Such as a raster image editor. I have some idea and C has exactly the right mix of simplicity and flexibility that I need. C is a constructor, and as a constructor it places few limits on what you can do. Other environments are way more rigid. E. g. I find Python way too rigid compared to C.
I fully agree, in fact I'm writing a game in C too, it's https://github.com/andreamonaco/zombieland.
Plus I have at least another idea for a game project in mind with the same language.
its funny how writing games in C is now seen as some kind of 'hardcore mode', despite the fact that a huge number of excellent titles up to and including the 2000s were written that way.
the core of games tend to be a 'world sim' of sorts, with a special case for when a select entity within the world sim gets its inputs from the user.
where C becomes a chore is the UI, probably has to do with how theres many more degrees of freedom (both in terms of possibilities and what humans consider appealing) in the visual plane than there is in the game input 'plane', which might be as little as 6 independent inputs plus time.
For quite some time even games technically written in C++ were more appropriately described as C compiled by a C++ toolchain with a minimum of actual C++ syntax - more like C with classes.
Has anyone got any good resources for something like this? I haven't touched C in years, and never worked on anything game-like. But it does look like a really interesting project to start something like this.
Plenty of people cycle on a fixie too. So what? C, especially modern C, does provide metaprogramming and abstraction facilities. In practice, you can even get things like the "defer" construct from other languages: https://lwn.net/Articles/934679/
The question isn't "Can I write a game in C?". Yes, of course you can, and it's not even that painful. The question is "Why would you?", and then "Why would you brag about it?"
> C++ covers my needs, but fails my wants badly. It is desperately complicated. Despite decent tooling it's easy to create insidious bugs. It is also slow to compile compared to C. It is high performance, and it offers features that C doesn't have; but features I don't want, and at a great complexity cost.
C++ is, practically speaking, a superset of C. It being "complicated"? The "insidious bugs"? It being "slow to compile"? All self-inflicted problems. The author of this article can't even fall back on the "well, my team will use all the fancy features if I let them use C++ at all!" argument pro-C-over-C++ people often lean on: he's the sole author of his projects! If he doesn't want to do template metaprogramming, he... just doesn't want to do it.
I don't read these sorts of article as technical position papers. People say, out loud, "I use C and not C++" to say something about themselves. ISTM that certain circles there's this perception that C is somehow more hardcore. Nah. Nobody's impressed by using it over a modern language. It really is like a fixie bicycle.
If he doesn't use C++ features then there's no point of bothering with C++ at all. C++ is kinda but not really a superset of C. There are some nice features that are lacking in C++.
The fixie example wants to make the comparison that using C instead of C++ is deliverately done just to brag about doing something in a way that is more difficult than in should be. In reality the issue is that C++ might not offer you any benefit at all and it could potentially bring you issues later on for things such as interfacing with other languages.
I personally do not see the point of using C++ if you do not use any of its features.
> People say, out loud, "I use C and not C++" to say something about themselves. ISTM that certain circles there's this perception that C is somehow more hardcore.
Sounds like this is just you projecting.
Almost any language has fewer footguns than C++, and thus programmers will take almost anything else over C++.
It's just incidental that "anything else" also includes C.
> I don't read these sorts of article as technical position papers.
I do.
> People say, out loud, "I use C and not C++" to say something about themselves.
Just like you are telling us something about yourself right now.
> ISTM that certain circles there's this perception that C is somehow more hardcore.
That's not why we use it.
There are certainly many noobs who think C is hardcore. That just goes to show how low the bar has fallen since the masses rushed into computing.
Many of these people also think of changing their own oil or a flat tire as being a superpower. Some could not identify the business end of a screwdriver if their life depended on it. Their opinion on the relatively difficulty or impressiveness of anything is to be taken with a huge grain of salt.
There are many good reasons to use C. If nothing else it demonstrates that the user is a free thinker and not a fucking muppet. It's the sort of thing that attracts me and drives you away. That's valuable.
> Nobody's impressed by using it over a modern language.
1) The word "modern" is not a magic talisman that makes anything it's attached to automatically worthy.
2) "Nobody" does not mean what you apparently think it means. Free clue: others exist in the world beside yourself and your self-absorbed clique.
3) Nobody with a brain is impressed by whatever the midwits are doing. Anyone who can fog a mirror can follow the herd off the nearest cliff. It's the outliers who are impressive.
4) Technically anything since the 1500s is "modern." It's such a vague, useless word that serves no purpose other than "virtue" signalling.
C++ is fucking garbage. Always has been. Keeps getting worse and worse every year. Enjoy your PAGES full of indecipherable gibberish ("error diagnostics"), your miserably slow compile times, and your closet full of footguns and decades old sticks of sweating dynamite. Slowest language by far, other than the so very modern abomination that is Rust. You can keep it.
I've been writing a good chunk of C lately for some stuff that has some relatively high memory constraints (lower than I could squeeze out of GraalVM).
I know I could do C++, and you could argue that's better, but I find C++ to be exceptionally irritating to use. Every time I've used C++ I get people telling me I'm using it "wrong", sometimes in contradictory ways. Sometimes I should use a "friend" function, sometimes "friend functions are evil". Sometimes multiple inheritance is fine, sometimes it should be avoided like the plague. Sometimes you should "obviously" use operator overloading, sometimes you should avoid it because it's confusing because you don't know which functions are being called.
I'm sure someone here can "educate" me with the best practices for C++, and maybe there will be some reasoning for it, but ultimately I don't really care. I just found the language annoying and I don't enjoy using it. I know that I could "just write it mostly like C and use the C++ features when I need it", but I have just found that I have more fun thinking in pure C, and I've kind of grown to enjoy the lack of features.
Maybe it's just a little bit of masochism on my end, but I like the fact that C gives you so little. You kind of have to think about your problem at a very fundamental and low level; you have to be aware of how memory is allocated and deallocated, you don't get all these sexy helper functional-programming constructs, strings aren't these simple automatic dynamic things that you have in basically every other language. You have a dumb, simple language that will give you exactly what you need to write programs and very little else.
Most stuff I write uses a garbage collector, but the safety and easy of writing stuff with garbage collectors like Java makes it very easy to be lazy. I've grown to appreciate how much C makes you actually think about problems.
> I know I could do C++, and you could argue that's better, but I find C++ to be exceptionally irritating to use. Every time I've used C++ I get people telling me I'm using it "wrong", sometimes in contradictory ways. Sometimes I should use a "friend" function, sometimes "friend functions are evil". Sometimes multiple inheritance is fine, sometimes it should be avoided like the plague. Sometimes you should "obviously" use operator overloading, sometimes you should avoid it because it's confusing because you don't know which functions are being called.
That is because you are looking at Design in C++ wrong. Language features and low-level abstractions are just mechanisms. You have to put them into a coherent framework for modeling a problem domain via commonality & variability analysis (aka domain engineering) onto a solution domain consisting of language features, idioms and patterns.
For a very good explanation, see the classic book, Multi-Paradigm Design for C++ by James Coplien.
IIRC go wasn't that fast but can feel like it in vscode. IIRC vscode compiles go using the lsp which is faster than launching a process because for some reason, vscode stalls for a second or more before launching a process.
I can't remember how fast D was but iirc it was fairly fast. Actual fastest is my compiler which I don't work on anymore and isn't ready for production. It's the only compiler I know of that hit millions of lines <1s in a non trivial language https://bolinlang.com/
Not every compiled language has a de facto standard compiler, but with SBCL Common Lisp compiles pretty quickly. The Pascals (and Delphi) also tend to have rather fast compile times. I believe Jai is supposed to compile quickly but I'm not in the beta so I don't know. C can be quite good if you know what you're doing and use a decent compiler.
I write all of my games in pure C++. C++ all the way. FMOD for the audio engine, Steam Audio or Atmoky TrueSpatial for HRTF/geometric occlusion, and Jolt Physics for, well, physics. I'm sure many might say I'm a bit insane to do that, but eh, I do it anyway because it's fun.
Before I even read the blog post, my first thought was: "Bullshit, this feels like clickbait. Simple DirectMedia Layer (SDL2) [one of the most popular gamedev libs for indy games] is written in pure C." I guess that the only backdoor to this clickbait argument in 2026 can be: "My graphics/audio libary is written in pure C, but I use bindings with language X (C++/Rust/Zig/etc)."
this is refreshing. personally i do all my hobby stuff in C or Python. I could certainly use c++ if i wanted to but templates and cin/cout were such monumental jokes how can i trust the rest of the language? i too have contemplated writing my own language but to paraphrase the author, id rather make games than languages and C/Python are good enough.
torlok|23 days ago
Complaining about a language having features you don't want is silly. C++ doesn't take longer to compile if you don't abuse templates.
pron|23 days ago
It might be silly if you're working on your own. Software that delivers a lot of value is usually developed and evolved not only by team, but by a team with changing members and changing leadership over the project's lifetime. The features used will be the union of all features used over the years, and while it's easy for team leads to allow the use of more features than their predecessors, it's quite hard to reduce them.
Also, you may be forced to use language features you don't want if they're used by libraries whose functionality you do want. For example, when doing low-level programming, I don't like implicit calls that I can't clearly see on the page (e.g. destructors or overloaded operators). But if libraries I want use them, then I'll have those implicit calls. But if the language doesn't have those features, libraries obviously won't use them.
flohofwoe|22 days ago
It actually does though, unless you also drop C++ stdlib usage completely (have you looked at how many lines of code just <vector> alone pulls into each source file? - it's upward of 20kloc and growing with each new C++ version).
And at that point you get into discussions with various C++ camps about why you don't use the C++ stdlib and instead prefer to reinvent the wheel (and this friction with other C++ coders is the main problem of carving out your own subset - it works ok in complete isolation, but software development work hardly happens in splendid isolation and even then you'd might to want to use C++ libraries written by other people from time to time...)
And once you've been dragged into such C++-subset-discussion month after month, year after year, at that point it is much less exhausting to just write plain C. And the C community (if it can be called that) seems to be much less concerned about coding style dogma and generally a nicer bunch to interact with.
FWIW, I switched around 2017 and each time I have to interact with a C++ library for lack of alternatives it's usually not a pleasant experience (with the notable exception of Dear ImGui - but even there I started to prefer the C bindings so that I don't need to strictly separate the UI code from the rest of the code base, which sometimes makes sense, but often not, especially with an immediate mode UI framework).
tialaramex|22 days ago
C++ dynamic dispatch (your "virtual interfaces") is achieved by welding a vtable onto every type and providing a pointer to that vtable for instances of the type. If in 90% of your code you deal with specific types like Goose or Swan or Duck or Seagull, and only 10% needs to work with the broad Bird category well, too bad, every Goose, Swan, Duck and Seagull carries around that vtable pointer even if it goes nowhere near that 10% of the system. This way your Bird code "just works" in C++.
That's not the only way to crack this nut. Idiomatic Rust approach uses vtables only in the Bird code, elsewhere they don't exist, and thus don't take up space in a Duck or whatever that's always a Duck, but in exchange now you're spending more time thinking, because by default there aren't any vtables and so dynamic dispatch isn't possible at all.
So while that C programmer has to implement features by hand, they are at least able to specifically implement the feature they wanted, not whatever was easiest for Bjarne Stroustrup last century.
petters|22 days ago
Surprisingly, this is not true. I've written a C++ file only to realize at the end that I did not use any C++ features. Renaming the file to .c halved the compilation time.
levodelellis|22 days ago
After writing that, I wrote my own standard library (it has data structs like vector, hashmap and sets; slices, strings, rng, print, some io functions, and more) which uses a lot of templates, and it compiles in <200ms on both clang and gcc. Many standard library headers take much longer to compile than that. It's not a terrible idea to have your own standard lib if you need quick compile times.
randomtoast|23 days ago
card_zero|22 days ago
feelamee|22 days ago
lelanthran|22 days ago
If your criteria for a good language is "how many features does it have", then sure, C++ wins. OTOH, if you criteria is "How many footguns does the language have" then C++ loses to almost every other mainstream language, which includes C.
Sometimes the lack of footguns is a plus.
pansa2|23 days ago
The main difference from choosing a different subset, e.g. “Google C++” (i.e. writing C++ according to the Google style guide), is that the compiler enforces that you stick to the subset.
krapp|23 days ago
I feel like if you need to implement modern language features, you shouldn't be using C. The entire point of C is to not be modern.
wasmperson|22 days ago
It's arguably irrational to evaluate a language based on this, but you can think of "this code could be better" as a sort of mild distraction. C++ is chock full of this kind of distraction.
etrvic|23 days ago
whizzter|23 days ago
HoldOnAMinute|22 days ago
A lot of smart people pick and choose what they want from the language, just like religion, they keep the good parts and discard the bad.
patrick451|22 days ago
bobajeff|22 days ago
Suppafly|22 days ago
That's definitely harder.
tomcam|23 days ago
Mindread much?
pyrolistical|23 days ago
This is why zig is a godsend. It is actually simpler than C while being more precise than C!
For example zig can distinguish between a pointer to a single element vs a pointer to an array of unknown length. Where as in c abi, it is all T*
When importing a c lib, you can make it more ergonomic to use than c itself.
Being able to easily import c lib is especially important to game dev, as practically all so called c++ libs also export a c header as they know how important it is.
https://github.com/zig-gamedev has a lot of repos of ziggified c libs used in games.
As for the preprocessor, zig comptime is so much better. It’s just more zig that runs at compile time.
dualogy|22 days ago
In the gamedev space, I'd say too few of them do.
vascocosta|23 days ago
That said, I also acknowledge that often times I need to solve problems that can benefit from a language that embraces what I call necessary complexity, but do it in elegant ways. Whenever I need to prioritise code correctness, especially memory and concurrency safety, using a mostly functional pattern instead of OOP, but without going as extreme as say Haskell, I unquestionably choose Rust, my favourite complex language. I often work with network code that is highly concurrent, must be as correct as possible and benefits from good performance, so then again, Rust feels natural here.
On the other hand, I love coding simple indie games and for that particular case, I like a simple and performant language using an imperative, non-OOP style. In my opinion C, and in particular Odin more recently are quite a good fit. If Jonathan happens to be reading this comment, since he mentioned Golang, I would suggest him Odin as perhaps the best of both worlds between C and Golang. It has all the simplicity of Golang, but without a garbage collector, plus it is quite easy to code a game using Raylib.
Zambyte|22 days ago
It's interesting to me that you say this, because it's the exact way that I describe Zig to people. Especially with the new std.Io async / concurrency changes. Do you feel Odin fits the space between Go and C better than Zig? Or just differently, and they both share the same space?
pjmlp|23 days ago
NewsaHackO|23 days ago
>The library support for games[in Go] is quite poor, and though you can wrap C libs without much trouble, doing so adds a lot of busy work.
I can't see when this was written, but it has to be around 2015. So, about 10 years ago. I wonder what his opinion is today.
QuantumNomad_|23 days ago
Also here is a snapshot of the main page of his website from that time, which has screenshots of his games and thereby provides context into what kind of games he had made and published when the blog post was written.
https://web.archive.org/web/20160110012902/http://jonathanwh...
This one looks like it’s 3d and has a pretty unique style:
https://web.archive.org/web/20160112060328/http://jonathanwh...
akoluthic|23 days ago
trueno|22 days ago
drnick1|23 days ago
jiggawatts|23 days ago
Unlike, say, Linux programming where C is the standard, almost all games have been written exclusively in C++ for a long time now, probably three decades.
pjmlp|23 days ago
indy|23 days ago
Keyframe|23 days ago
uecker|23 days ago
NuclearPM|23 days ago
Say more with less.
heliumtera|23 days ago
linux attracted 2,134 developers in 2025
that kinda weakens your argument a little bit
stephc_int13|23 days ago
Well, this should be reformulated a bit. Using C is not the norm, but it once was and many people are still using C to write games, myself included.
IshKebab|22 days ago
quotemstr|23 days ago
I'm no Go fan, to be clear, but GC isn't the problem with Go. It has a pretty decent GC with sub-millisecond pause times. People who complain about GC pauses while extolling the virtues of manual memory management are running on a set of prejudices from 1999 and are badly in need of a mental firmware update.
carefree-bob|22 days ago
I agree that it really isn't about garbage collection pauses, but I haven't heard people focusing on "eliminating gc pause" when they talk about low level languages, but they spend a lot of time talking about SIMD, GPU kernels, and cache misses. If Go could add these features, it would be a performance monster.
nasretdinov|23 days ago
Bengalilol|23 days ago
smallstepforman|22 days ago
nurettin|22 days ago
teunispeters|22 days ago
Very useful if you don't want (or need) surprises anywhere. Or if you want all the surprises (exceptions, errors, etc) all better tied to the hardware that provides such.
It's also fairly easy to write unit tests for everything.
p0w3n3d|23 days ago
But I find string management in C awful and would like to borrow it from C++. Only the string management
direwolf20|23 days ago
JamesTRexx|22 days ago
Things I noticed are inconsistent coding styles, overly complex processes, unused(!) functions, inefficient data use, nothing surprising with a project worked on by various people in their spare time and their own ideas on how to code. And this isn't even talking about later versions. To me it's an example of how unrestricted access to bling features causes a mess.
Eventually I want it converted to C (C23), split apart in seperate functions with a decent source code organisation, and simplified processes to make it easier to understand what's going on and extend fuctionality. For this I need it simplified as possible and weed out the layer of complexity caused by C++ first. Going to take plenty of time, but I'm still having fun doing it (most of the time anyway :-p ).
I'm not advocating anything, but it's satifying to me to bring clarity to code and see small improvements to performance during the process at the same time. It also gave me an opportunity to develop a unique syntax style that visualises parts of the code better for me.
uecker|22 days ago
guerrilla|22 days ago
That said, "I am dead" is a very real video game indeed... and his arguments are very sound. I also can't stand C++. I disagree with him on Java though. The core language of Java is actually super simple, like C.
tuhgdetzhh|22 days ago
I agree on C++ being the worst of both worlds for many people. You get abstraction, but also an enormous semantic surface area and footguns everywhere. Java is interesting because the core language is indeed small and boring in a good way, much closer to C than people admit. The productivity gains mostly come from the standard library, GC, and tooling rather than clever language features. For games, the real disagreement is usually about who controls allocation, lifetime, and performance cliffs, not syntax.
direwolf20|22 days ago
Andrex|22 days ago
Not being facetious, but couldn't you say that about almost any language? What makes you say it about Java?
giancarlostoro|22 days ago
ddtaylor|22 days ago
csb6|22 days ago
direwolf20|22 days ago
leecommamichael|23 days ago
doublerabbit|22 days ago
Time escapes me before I get a chance to type Hello World. Working in front of a screen eight hours a day leaves me exhausted that the least things I want to do is code more on my day off.
Although wanting to dive in to WASM has been a priority and checking Odin for wasm their 3D model example is super cool.
May just have to take a poke. TCL for web frontend; Erlang for DB and potentially Odin for wasm? This could be a cool mix.
andai|23 days ago
Did a bit of game dev in Odin last year and it was a wonderful experience. It's very much game dev oriented and comes batteries included with many useful libraries. And the built in vector stuff is very helpful there too.
pjmlp|23 days ago
Then Watcom C/C++ made it quite easy to use C++ for game development on PCs, PlayStation 2 introduced support for C++, quickly followed up by XBox and Nintendo, and that was it.
kahlonel|22 days ago
zzo38computer|22 days ago
HeavyStorm|23 days ago
brokencode|23 days ago
unknown|23 days ago
[deleted]
andreldm|23 days ago
dismalaf|23 days ago
Mikhail_Edoshin|22 days ago
seabrookmx|22 days ago
andreamonaco|22 days ago
webdevver|23 days ago
the core of games tend to be a 'world sim' of sorts, with a special case for when a select entity within the world sim gets its inputs from the user.
where C becomes a chore is the UI, probably has to do with how theres many more degrees of freedom (both in terms of possibilities and what humans consider appealing) in the visual plane than there is in the game input 'plane', which might be as little as 6 independent inputs plus time.
namuol|23 days ago
Try Clay!
https://www.nicbarker.com/clay
pengaru|23 days ago
glimshe|22 days ago
howToTestFE|22 days ago
lylejantzi3rd|22 days ago
https://guide.handmadehero.org/code/
anatoly|22 days ago
quotemstr|23 days ago
The question isn't "Can I write a game in C?". Yes, of course you can, and it's not even that painful. The question is "Why would you?", and then "Why would you brag about it?"
> C++ covers my needs, but fails my wants badly. It is desperately complicated. Despite decent tooling it's easy to create insidious bugs. It is also slow to compile compared to C. It is high performance, and it offers features that C doesn't have; but features I don't want, and at a great complexity cost.
C++ is, practically speaking, a superset of C. It being "complicated"? The "insidious bugs"? It being "slow to compile"? All self-inflicted problems. The author of this article can't even fall back on the "well, my team will use all the fancy features if I let them use C++ at all!" argument pro-C-over-C++ people often lean on: he's the sole author of his projects! If he doesn't want to do template metaprogramming, he... just doesn't want to do it.
I don't read these sorts of article as technical position papers. People say, out loud, "I use C and not C++" to say something about themselves. ISTM that certain circles there's this perception that C is somehow more hardcore. Nah. Nobody's impressed by using it over a modern language. It really is like a fixie bicycle.
wudangmonk|22 days ago
The fixie example wants to make the comparison that using C instead of C++ is deliverately done just to brag about doing something in a way that is more difficult than in should be. In reality the issue is that C++ might not offer you any benefit at all and it could potentially bring you issues later on for things such as interfacing with other languages.
I personally do not see the point of using C++ if you do not use any of its features.
lelanthran|22 days ago
Sounds like this is just you projecting.
Almost any language has fewer footguns than C++, and thus programmers will take almost anything else over C++.
It's just incidental that "anything else" also includes C.
enricotr|23 days ago
its_magic|22 days ago
I do.
> People say, out loud, "I use C and not C++" to say something about themselves.
Just like you are telling us something about yourself right now.
> ISTM that certain circles there's this perception that C is somehow more hardcore.
That's not why we use it.
There are certainly many noobs who think C is hardcore. That just goes to show how low the bar has fallen since the masses rushed into computing.
Many of these people also think of changing their own oil or a flat tire as being a superpower. Some could not identify the business end of a screwdriver if their life depended on it. Their opinion on the relatively difficulty or impressiveness of anything is to be taken with a huge grain of salt.
There are many good reasons to use C. If nothing else it demonstrates that the user is a free thinker and not a fucking muppet. It's the sort of thing that attracts me and drives you away. That's valuable.
> Nobody's impressed by using it over a modern language.
1) The word "modern" is not a magic talisman that makes anything it's attached to automatically worthy.
2) "Nobody" does not mean what you apparently think it means. Free clue: others exist in the world beside yourself and your self-absorbed clique.
3) Nobody with a brain is impressed by whatever the midwits are doing. Anyone who can fog a mirror can follow the herd off the nearest cliff. It's the outliers who are impressive.
4) Technically anything since the 1500s is "modern." It's such a vague, useless word that serves no purpose other than "virtue" signalling.
C++ is fucking garbage. Always has been. Keeps getting worse and worse every year. Enjoy your PAGES full of indecipherable gibberish ("error diagnostics"), your miserably slow compile times, and your closet full of footguns and decades old sticks of sweating dynamite. Slowest language by far, other than the so very modern abomination that is Rust. You can keep it.
tombert|22 days ago
I know I could do C++, and you could argue that's better, but I find C++ to be exceptionally irritating to use. Every time I've used C++ I get people telling me I'm using it "wrong", sometimes in contradictory ways. Sometimes I should use a "friend" function, sometimes "friend functions are evil". Sometimes multiple inheritance is fine, sometimes it should be avoided like the plague. Sometimes you should "obviously" use operator overloading, sometimes you should avoid it because it's confusing because you don't know which functions are being called.
I'm sure someone here can "educate" me with the best practices for C++, and maybe there will be some reasoning for it, but ultimately I don't really care. I just found the language annoying and I don't enjoy using it. I know that I could "just write it mostly like C and use the C++ features when I need it", but I have just found that I have more fun thinking in pure C, and I've kind of grown to enjoy the lack of features.
Maybe it's just a little bit of masochism on my end, but I like the fact that C gives you so little. You kind of have to think about your problem at a very fundamental and low level; you have to be aware of how memory is allocated and deallocated, you don't get all these sexy helper functional-programming constructs, strings aren't these simple automatic dynamic things that you have in basically every other language. You have a dumb, simple language that will give you exactly what you need to write programs and very little else.
Most stuff I write uses a garbage collector, but the safety and easy of writing stuff with garbage collectors like Java makes it very easy to be lazy. I've grown to appreciate how much C makes you actually think about problems.
rramadass|21 days ago
That is because you are looking at Design in C++ wrong. Language features and low-level abstractions are just mechanisms. You have to put them into a coherent framework for modeling a problem domain via commonality & variability analysis (aka domain engineering) onto a solution domain consisting of language features, idioms and patterns.
For a very good explanation, see the classic book, Multi-Paradigm Design for C++ by James Coplien.
The above can also be found in his PhD thesis Multi-Paradigm Design available in pdf form here - https://tobeagile.com/wp-content/uploads/2011/12/CoplienThes...
cyh555|22 days ago
parasti|22 days ago
graemep|23 days ago
What languages compile fastest?
levodelellis|22 days ago
I can't remember how fast D was but iirc it was fairly fast. Actual fastest is my compiler which I don't work on anymore and isn't ready for production. It's the only compiler I know of that hit millions of lines <1s in a non trivial language https://bolinlang.com/
tmtvl|22 days ago
gfody|22 days ago
elcritch|22 days ago
arcologies1985|23 days ago
mapcars|23 days ago
Because they use Typescript.
>The stop-the-world garbage collection is a big pain for games
There is a number of languages that allow manual memory management: Zig, Nim, Rust and few others
archargelod|22 days ago
Nim not only has support for manual memory management, but there're several gc modes that are not stop-the-world.
Also, since Nim 2, the stdlib now is using ARC by default, which is deterministic and has advantages over conventional garbage collection.
andai|23 days ago
naranyala|21 days ago
alexmyczko|22 days ago
ethin|23 days ago
throwaway2037|22 days ago
zuluonezero|22 days ago
unknown|22 days ago
[deleted]
nottorp|22 days ago
globalnode|22 days ago
Western0|22 days ago
because You know C
sylware|22 days ago
[deleted]
zenlot|22 days ago
[deleted]