Why C++17 is the new programming language for games I want

Posted by Matt Newport on 10 November 2014

I've been watching Jonathan Blow's recent YouTube videos about his Ideas about a new programming language for games (plus Part 2 and Part 3). Jonathan makes many good points in the videos and has some interesting ideas in the language and compiler he is building but in this series of posts I'm going to make the case for why I think C++14 already goes a long way towards being the new programming language for games that I want to use and C++17 goes further still.

Just to be clear upfront about my 'agenda', I really like modern C++. It's the language I want to use for my day to day work. I don't subscribe to the idea that it's a mess of a language that I'm just stuck with using because there's no viable better options out there. I think it's great that Jonathan is creating this discussion and trying out new ideas but in general I'd rather see effort devoted to improving C++ through the standards committee process and through building better tools and libraries than see it devoted to building a replacement for C++.

I'm going to show how C++14 already allows me to do many of the things Jonathan talks about as desirable language features with pretty concise syntax. The syntax is not identical to Jonathan's but to me the differences are not sufficient to justify moving to a whole new language. I'm also going to give examples of where I think C++ either already solves certain problems better than the solutions Jonathan proposes or has new language or library features under discussion that will offer better solutions.

Jonathan says at various times in his videos not to get too hung up on any particular syntax. At other times he also says that syntax is important (when discussing unique_ptr vs. his proposed owning pointer syntax for example). I don't necessarily think he's contradicting himself here but it does make it a little unclear where he'd draw the line in terms of justifying a new language purely for syntax improvements. My own view is that syntax is important, but I'm willing to live with slightly sub-optimal C++ syntax in certain cases - I've yet to see an example that justifies moving to a whole new language but that said, I'm an enthusiastic adopter / advocate of syntactic improvements that have been brought to C++11, C++14 and beyond.

I also want to mention some problems that I do think C++ suffers from that will be difficult to fix by evolving the language that I haven't seen Jonathan address. Rust seems like it might offer a long term solution to some of these fundamental problems but I only have a cursory familiarity with it at this point.

I first want to get out of the way some things that I definitely want to see in C++ that are not yet standardized but are in the process of standardization:

Modules are largely about reducing compile times and also have the potential to make it easier to build semantic aware tools in C++ IDEs. Jonathan talks a bit about the problems of header files in C++ and this is definitely a big issue in practice. The modules proposal looks very promising to me and if I could only get one current proposal in C++17 it's the one I'd probably pick!

Reflection is what Jonathan sometimes refers to as introspection. The current proposal is targeted at compile time reflection rather than runtime reflection but it should greatly simplify serialization, the most compelling use case IMO.

Jonathan included a warning / disclaimer about his video containing a lot of opinions. I want to make a similar disclaimer. I'm going to disagree with a lot of what he says in his videos and at times in strong terms. None of this is intended as an attack on Jonathan personally however - I have a lot of respect for his work, both his games and his technical articles over the years that I've got a lot of value out of. I'm also fully on board with what I take to be his main aim - getting to a place where day to day programming is a more enjoyable, more productive and less frustrating experience through improving the experience of using our primary tool, the language we work with. My posts are going to be focused on the areas we disagree, there's plenty of points he makes that I do agree with that I won't be addressing.

Since there's a lot of material I want to cover, I'm going to break this up into a series of posts. The table of contents here will be kept up to date with the current set of posts.