Why I Write Games in C (yes, C)

Unfortunately OCaml is single-threaded, has a stop the world GC (though if it’s good enough for Jane Street it’s probably good enough for you), and sometimes has unfortunate syntax (though ReasonML fixes a lot of this). Also OCaml doesn’t have the greatest type system in the world. No higher kinder types and instead we get the parameterized “functor” module system. Which honestly, kind of sucks. A lot of OCaml is an artifact from the past, if it could be remade today it would really be something great. Even so, OCaml is a great language and doesn’t suffer from a lot of the dogma that Haskell succumbs to.

I’ve always thought of and used OCaml as the functional programming equivalent of C. No unnecessary bullshit, just straight coding.

A cursory look at the CVE list for any C software in the wild indicates that no, there are not simple ways to avoid shooting yourself in the feet with manual memory management in C. It's _incredibly hard_ even for "elite" programmers who have a lot of incentive to avoid these problems. The counterpoint is that people are probably going to spend less time looking for ways to maliciously use those problems in your C game than they are in the Linux kernel, but there is plenty of potential for even seasoned C coders to engage in bullet-on-foot violence.

I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage collector is doing work that doesn't need to be done. What latency budgets are you working with? How often do you do work to free resources? What are the latency requirements there? Even at 144 fps, that's 7ms per frame. If you have a garbage collector that runs in 200us, you could run a GC on every single frame and use less than 3% of your frame budget on the GC pause. I'm -not- suggesting that running a GC on every frame is a good idea or that it should be done, but what I find so deeply frustrating is that the argument that GC can't work in a game engine is never qualified.

edit: wow for once the replies are actually good, very pleased with this discussion.

The goal (at least mine and of some authors following this minority trend) is to write and read simpler, more straightforward code.

Take a look at the code in the examples of the following url to see what I mean.

https://www.raylib.com/examples.html

1. Complexity of implementation is not complexity of use. Example: Take std::array vs a plain C array. std::array is a few hundreds of lines of code. But - it's about as inutitive to use; has more convenience features; easier for the compiler to optimize; and doesn't let you should yourself in the foot that easily.

2. If Whiting don't want _any_ of the features of C++ - his software-writing skills are suspect. Now, few people need or want all of C++'s features - but C's are definitely insufficient, especially if you consider both the langauge and some of the standard library (or non-standard common libraries).

3. The complexity you have to tackle with C++ is lower than the complexity of non-standardized often-inconsistent idiosyncratic platforms and libraries for achieving the same things with C (or C + assembly).

So I find Whiting's argument for C over C++ unconvincing. IMHO C++ would be the least-bad language for writing demanding games in.