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 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.
I measured once and to my surprise templates aren't 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 (contains 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.
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.
> 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.
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.
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.
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.
For a solo dev, it's not difficult. C++ is nearly a superset of C. You don't have to adopt all of C++ to start using it and to get immediate benefits from it (for example, unique_ptr, shared_ptr, and vector would all be things that I think any C dev would really appreciate).
A reason I can think of to not move to C++ is that it is a vast language and, if you are working on a team, it can be easy for team members ultimately forcing the whole team to become an expert in C++ simply because they all will be familiar with a different set of C++ features.
But for a solo dev? No reason not to use it, IMO. It's got a much nicer standard library with a rich set of datastructures that just make it easier to write correct code even if you keep a C style for everything.
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.
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.
A switch statement is how you do ad-hoc polymorphism in C -- i dont thinks an own against C developers to point that out. If they wanted to adopt the C++ style that immediately requires the entire machinery of OOP, which is an incredibly heavy price to avoid a few switch statements in the tiny number of places ad-hoc poly is actually needed
You don't usually do C++ subsets if you want the full shebang.
I have a "mini-std" headerfile that's about 500 LoC implementing lightweight variants of std::vector, std::function, a stack-local std::function (unsafe as hell and useful as hell to avoid allocations), a shared-ptr, qsort and some other nifty stuff.
That does a lot of things, but even then I use other patterns that brings a lot of bang for the buck without having to go full C (hint: the stack-local function equivalent gets a lot of mileage).
See also: reinventing templates in C using horrific pre-processor hacks. At that point you're creating the same amount of code bloat as a simple C++ template but with even worse syntax.
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 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.
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 know, but I often use Golang for two reasons: 1. avoids confusion, no matter how unlikely it is in a context like HN, and 2. search engine "findability".
> 1. avoids confusion, no matter how unlikely it is in a context like HN
Who would be confused by "Go", but not "Rust" and "Zig", which are also common English words not usually associated with programming languages?
> 2. search engine "findability".
What kind of search engine are you using in 2026 that isn't capable of understanding context?
And where one is still using some weird antique thing like a steampunk character, "C" is going to be the least findable, yet it didn't receive the same treatment. Why is that?
The use of "golang" for posts and comments is desirable IMHO because it greatly facilitates search, especially on sites such as HN that cover many languages.
Searching "site:news.ycombinator.com go" on Google didn't yield any results that weren't about the Go programming language even after going several pages deep. What kind of search problems are you having, exactly?
And why is it unique to Go? I am sure there are comments on HN about metal oxidization, making sharp changes in direction, Norse gods, and letters of the alphabet.
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.
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
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++.
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.
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.
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.
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.
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++.
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.
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.
There are a few exceptions though, like most mobile games, visual novels (many of which use Python of all languages, due to an excellent framework called ren'py), and of course games written using Unity or XNA, which use .NET languages.
Also, three decades is going a bit too far back, I think. In the mid nineties, C was still king, with assembly still hanging on. C++ was just one of several promising candidates, with some brave souls even trying Java.
In J2ME feature phones Java was all there was, and even today many indies do use it on casual titles on Android.
Which is why after so much resistance not wanting to use the NDK for Vulkan, and keeping using OpenGL ES from those devs, Google is bringing WebGPU to Java and Kotlin devs on Android.
Announced at last Vulkanised, there is already an alpha version available, and they should talk more about it on upcoming Vulkanised.
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.
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.
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 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.
> 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.
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.
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.
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 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.
I measured once and to my surprise templates aren't 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 (contains 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.
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.
> 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.
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 don't believe you, I measured compile times in c compilers and my own. If you provide more information I'd be more likely to believe you
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.
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.
For a solo dev, it's not difficult. C++ is nearly a superset of C. You don't have to adopt all of C++ to start using it and to get immediate benefits from it (for example, unique_ptr, shared_ptr, and vector would all be things that I think any C dev would really appreciate).
A reason I can think of to not move to C++ is that it is a vast language and, if you are working on a team, it can be easy for team members ultimately forcing the whole team to become an expert in C++ simply because they all will be familiar with a different set of C++ features.
But for a solo dev? No reason not to use it, IMO. It's got a much nicer standard library with a rich set of datastructures that just make it easier to write correct code even if you keep a C style for everything.
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.
C's string handling is so abominably terrible that sometimes all people really need is "C with std::string".
Oh, and smart pointers too.
And hash maps.
Vectors too while we're at it.
I think that's it.
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.
A switch statement is how you do ad-hoc polymorphism in C -- i dont thinks an own against C developers to point that out. If they wanted to adopt the C++ style that immediately requires the entire machinery of OOP, which is an incredibly heavy price to avoid a few switch statements in the tiny number of places ad-hoc poly is actually needed
You don't usually do C++ subsets if you want the full shebang.
I have a "mini-std" headerfile that's about 500 LoC implementing lightweight variants of std::vector, std::function, a stack-local std::function (unsafe as hell and useful as hell to avoid allocations), a shared-ptr, qsort and some other nifty stuff.
That does a lot of things, but even then I use other patterns that brings a lot of bang for the buck without having to go full C (hint: the stack-local function equivalent gets a lot of mileage).
This reads like an LLM generated response that simply restates the comment it's replying to
Heck the LLM accusations get a bit out of hand lately here on HN. I could delve into it now ... but I want to safe our time.
> but it’s not obviously simpler or safer
On top of likely having worse performance.
See also: reinventing templates in C using horrific pre-processor hacks. At that point you're creating the same amount of code bloat as a simple C++ template but with even worse syntax.
It's important that you do these things yourself before you utilise the compiler to do them for you, so you have real understanding.
> just to feel better about themselves.
Mindread much?
>Writing games in C is not harder, you just have to implement modern language features by hand.
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.
>Death of flash
>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.
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.
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...
It's not unheard of, but you have to be a little crazy to do this in 2026. I developed Chrysalis entirely in C (with GLFW3 and FMOD for audio): https://store.steampowered.com/app/1594210/Chrysalis/
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.
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.
The language is called Go, golang is the website domain.
I know, but I often use Golang for two reasons: 1. avoids confusion, no matter how unlikely it is in a context like HN, and 2. search engine "findability".
> 1. avoids confusion, no matter how unlikely it is in a context like HN
Who would be confused by "Go", but not "Rust" and "Zig", which are also common English words not usually associated with programming languages?
> 2. search engine "findability".
What kind of search engine are you using in 2026 that isn't capable of understanding context?
And where one is still using some weird antique thing like a steampunk character, "C" is going to be the least findable, yet it didn't receive the same treatment. Why is that?
The use of "golang" for posts and comments is desirable IMHO because it greatly facilitates search, especially on sites such as HN that cover many languages.
Searching "site:news.ycombinator.com go" on Google didn't yield any results that weren't about the Go programming language even after going several pages deep. What kind of search problems are you having, exactly?
And why is it unique to Go? I am sure there are comments on HN about metal oxidization, making sharp changes in direction, Norse gods, and letters of the alphabet.
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.
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.
"nobody does this"
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.
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
That's the neat thing about C++. You don't have to use any of it.
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++.
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.
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.
> 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
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.
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.
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++.
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.
Additionally SDL3 is also C and the most recent version of the Box2d physics library was rewritten in 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.
There are a few exceptions though, like most mobile games, visual novels (many of which use Python of all languages, due to an excellent framework called ren'py), and of course games written using Unity or XNA, which use .NET languages.
Also, three decades is going a bit too far back, I think. In the mid nineties, C was still king, with assembly still hanging on. C++ was just one of several promising candidates, with some brave souls even trying Java.
In J2ME feature phones Java was all there was, and even today many indies do use it on casual titles on Android.
Which is why after so much resistance not wanting to use the NDK for Vulkan, and keeping using OpenGL ES from those devs, Google is bringing WebGPU to Java and Kotlin devs on Android.
Announced at last Vulkanised, there is already an alpha version available, and they should talk more about it on upcoming Vulkanised.
COM was designed to be compatible with C.
People did do that, 30 years 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.
Wrong. I’m still doing it.
>I really dislike javascript, it is so loose that I marvel that people are able to write big chunks of software in it. I have no interest in trying.
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
Yes, C. Like all id games up to... Doom 3, if I'm not mistaken? Only then they switched to C++. There's absolutely nothing impressive about this fact.
Nobody claimed it was impressive. It’s a little unusual to use C instead of C++, but that’s about it.
Come try Odin!
I've been doing theory and really want to myself.
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.
+1 for Odin
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.
I was also really surprised with Haxe, I share the author’s concerns about its future, other than it’s quite fun to work with.
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.
> when it comes to compilation I can't think of anything faster.
What languages compile fastest?
Rust can be up there with C depending on the project.
Any language can be, depending on the project. Rust compile is slower than C, on more than average. That's it.
is that a joke?
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.
> 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.
Yeah I was a bit surprised by this too. I think the post was written around 10 years ago, when it still was a genuine problem in Go.
Good eye. This is why HN titles have year tags. :-)
Yeah, this is from 2016. I don't think choosing C over C++ was defensible even back then, but the critique of Go makes more sense now.
https://web.archive.org/web/20160109171250/http://jonathanwh...
(2016)
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.
> UI in C
Try Clay!
https://www.nicbarker.com/clay
There’s also CimGUI. I know the underlying C++ library is well-regarded - I’m curious to hear people’s experiences using the C wrapper.
https://github.com/cimgui/cimgui
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.
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.
"Practically speaking" means nothing. Use "from my confused point of view", instead.
If GDB could switch its C codebase to compiling as C++ without major surgery, it's close enough.