
C or C++ for my game engine? - AlexeyBrin
http://crafn.kapsi.fi/new_engine.html
======
crafn
Author here. I'm positively surprised, constructive discussion on internet!

There's been some discussion about using Rust.

Rust is an interesting language, and has definitely potential substituting C
and C++ in some domains. The main reason I'm not so interested in using it is
for game development, is because it's more complicated than C (like C++), and
the complications are a bit off from what I'd want (like in C++). Just a quick
googling reveals that rust mangles names by default, and doesn't have
reflection, so I'd probably be in for a lot of negative surprises. Add that
with being indifferent about the absolute security, and soon my code is mostly
inside unsafe blocks so that I don't have to spend time convincing the
compiler my pointers are safe. Maybe. I haven't done much programming in Rust.
There are some nice convenience features though, when comparing to C, but they
seem to be rather minor things.

It comes down to choosing between two non-ideal solutions. I value simplicity
more than some, so favoring the simpler one feels more natural to me. Sure,
when you need the safety then Rust seems like a decent choice.

~~~
dikaiosune
Only responding to one element of your comment -- but I think that Rust's
safety features are over-marketed in my experience. The safety Rust offers is
only part of a package that provides high-performance high-level abstractions
over functionality that is normally very bit-twiddly in C. So far, my favorite
thing about Rust is not its safety, but how easy it is to write good
performance software using abstractions that are as convenient as Python (or
another high-level language). The safety is just icing on the cake at that
point (for me at least).

EDIT: Re: pointers -- Rust is a lot easier to write if you just ignore
pointers. Really. Either pass small structs by value or pass references
(either immutable or mutable), and let the compiler handle the actual pointer
manipulation.

~~~
pjmlp
I think they are marketed exactly well.

If it wasn't for the uptake of UNIX, we probably would never had to discuss
about memory corruption in 2016, other than writing stuff like device drivers.

There is now a whole generation that thinks C was the very first systems
programming language, the compilers were as good on day 1 as they are today
and it has became some kind of sacred cow.

[http://www.itsecdb.com/oval/definitions/product-47/0/Linux-L...](http://www.itsecdb.com/oval/definitions/product-47/0/Linux-
Linux-Kernel.html?family=unix)

Regarding memory corruption and games, it is how we get around to achieve game
cheats.

~~~
dikaiosune
I don't think Rust's safety guarantees are over-marketed because they aren't
important, but because many of the benefits of the language/stdlib/tooling are
available to people who don't frequently have to deal with memory corruption.
It's not that the safety isn't valuable (I just about pulled all my hair our
implementing custom data structures in C++ last time I did it), but that most
developers think it's not as useful as other marketable elements of the
language.

------
rootw0rm
I can sense the pitchforks coming out already! A quick disclaimer first of
all: I LOVE C. Love love love it. I'm a reverser so it's my native tongue. I
get as much joy from the actual creative process of coding and playing with
pointers as I do from having a reliable working finished project.

No offense, but I think you suffer from the same problem. You're in love with
coding, so being forced to micro-manage things the 'C' way isn't a problem for
you.

But at some point in time you have to look back and justify the hours spent.
You -will- be more productive by having the majority of your code in C++ 11.
Things -will- be easier to maintain for yourself and others.

I have written absolutely brilliant C code that I'm very proud of, but if it's
been a while since I looked at the project I have to sit down for an hour and
re-familiarize myself with how things work....and I'm the one who wrote it.

Based on what you've written I can tell that you don't have the experience to
justify writing the bulk of your code in C. Guys who inline ASM all day long
can have a hard time doing that. I know it's harsh, but it's meant as helpful
criticism.

One other thing: You don't have to pick just C or just C++. If you have
engines in your project that are clearly better in C and you enjoy doing it,
more power to you....I encourage you to do that. However, it's very easy to
get hung up on C and lost in your own C world of imagined optimizations.

My advice: Start off with solid C++, move parts to C later on when testing
justifies it and your amount of free time justifies it.

~~~
microcolonel
I don't think you're addressing the concerns which made him choose C. In his
case: debugging is complex, compilation is slow, name mangling is unreliable,
global state is abound.

He makes no mention of inline assembler, nor does he encourage premature
optimization. He talks instead about a concrete problem he had: the typical
performance of operations was not good enough, thus no single optimization
would help much. He also mentions that the abstractions encouraged by C++ do
not help you build data-oriented applications (e.g. games); using them
properly actually hurts performance.

~~~
amagumori
meh - imo, even if C++ is a ridiculously bloated beast, it has some things
that are indispensable for game programming that C doesn't. vector math
without operator overloading is gross. being able to have generic containers
with templates is really useful, even if templates are gross. encapsulating
functionality in classes is always useful, and you can get a lot of use out of
inheritance without overusing it.

these things are really codebase readability and maintainability concerns, and
to me they're orthogonal to "data-oriented programming", things like
optimizing for cache locality, SoA instead of AoS, not calling virtual methods
in warm or hot paths, throwing away malloc and using purpose-built custom
allocators, SIMD/AVXify all the things, etc. etc.

it's a lot harder to handle the insane, byzantine complexity of a game engine
in something as pared-down as C.

with that said, i don't like C++ and i definitely don't think it's a beautiful
language by any means.

jonathan blow's new language, jai, is very interesting. purpose-built for game
programming. check it out if you don't know about it yet. it's looking really
promising for all types of high-performance, game-like projects.

~~~
exDM69
> vector math without operator overloading is gross.

Many C compilers can use normal infix operators with SIMD vectors and it will
have better performance than C++ operator overloading (especially in debug
builds). All you need is a typedef.

    
    
        typedef float vec4f __attribute__ ((vector_size (16)));
        vec4f a = { 1, 2, 3, 4 }, b = { 5, 6, 7, 8 };
        vec4f c = a * (a + b);
    

The typedef is slightly different for Clang, but that's just one line. This
code should work with GCC, Clang and the Intel C compiler. MSVC doesn't do
this, but I don't write code for MSVC any more because I can compile
compatible object files with Clang.

In my experiments, I've noticed that you get the best performance by passing
vectors and matrices by value, not by pointer or reference. It also makes the
API nice, because you can return matrix values, e.g. `mat4x4f mvp =
matrix_product(projection, matrix_product(model, view))`. In some nasty cases
you might need to add force_inline attribute, but most of the time the
compiler will inline the functions anyway.

In C++ with operator overloading it's easy to do stupid things like in-place
addition (e.g. operator+= for a vec4f) or start transposing matrices in place.
This will make the compiler emit memory load/store instructions when you'd
want to have these values in registers.

> being able to have generic containers with templates

Generic containers are somewhat of an issue with C, but most of the
std::containers are not suitable for some game development tasks (this is why
projects like eastl exists). I prefer using intrusive containers in C, similar
to how the Linux kernel deals with linked lists and red-black trees. Even the
C++ standard library (the GNU one) is internally implemented this way, the
"generic container" is just a thin type safety shim on top to avoid template
bloat.

~~~
pcwalton
> In C++ with operator overloading it's easy to do stupid things like in-place
> addition (e.g. operator+= for a vec4f) or start transposing matrices in
> place. This will make the compiler emit memory load/store instructions when
> you'd want to have these values in registers.

That sounds like a failure of inlining. If you're at the point where a single
stack spill makes a difference, you won't want to pay the cost of the calling
convention spills either. And if you _are_ inlining, then SROA and mem2reg
will easily remove those load/store instructions. Modern compiler
optimizations make what you describe not a problem anymore.

~~~
exDM69
> Modern compiler optimizations make what you describe not a problem anymore.

Yes, it _should_ get inlined, but I've seen this fail in a recent-ish GCC (4.6
to 4.8 or so). And there's still the issue of debug builds being slower even
if the compiler works perfectly in optimized builds.

Operator overloading will only work with SIMD if you write your vector class
using intrinsics or SIMD extensions anyway. If you're doing scalar loads and
stores, you can't rely on getting SIMD instructions in the output.

~~~
pcwalton
> Yes, it should get inlined, but I've seen this fail in a recent-ish GCC (4.6
> to 4.8 or so)

Seems like a pretty bad GCC bug then, one that should be fixed upstream.

I really dislike it when code avoids functions because of fear that they won't
be inlined (or to try to work around compiler bugs to that effect), because
doing this dramatically reduces code maintainability and safety in exchange
for very little benefit, given the inline hint keyword and
__attribute__((always_inline)).

~~~
exDM69
GCC's inlining has been a bit brittle, especially when dealing with vector
arguments, and also depending on the ABI (4x double vectors without AVX, etc).
It's much better in GCC 5.x now.

I generally use always_inline for vector arithmetic functions, just to be
sure. You never want to have a function call to do just a few SIMD
instructions.

------
golergka
You speak about perfomance a lot, but do you actually have it as an important
requirement, or is it just fun problem to tackle as programmer? In modern game
development, it's usually the latter — most hobby game projects don't have art
assets detailed enough to be slow on platforms where your end-users actually
will play your game.

I make games in Unity/C#, and yes, of course it's slower than a custom C
solution. But instead of spending time on writing my own containers and memory
allocation, I spend time writing game logic. Instead of optimizing game to run
from 100 to 150 FPS on my computer, I'd rather spend this productive time
making 5 variants of the same game mechanic to find out which is more fun.
Even if the game runs in just 30 FPS.

Of course, I sometimes try to research low-level stuff, write my own renderer,
or do a small experimental project in pure C, but then my goal is to research,
not to write a game. I can hardly imagine a project, where the goal would be
to develop a game, and not to research, where using C and having to spend so
much time on this matters would be a good trade-off compared to working on
actual game mechanics in higher-level language.

~~~
tinco
Unity is written in C. That the game logic is written in C# is hardly relevant
as you explain. In fact this guy might still embed C# at some point if he
wishes for his logic to be less painful to write.

The author states at the beginning that his goal is writing an engine and only
after that write a game. You are right on all other points though, most people
working on game engines simply never get to the making a game part. There's
simply too much to do.

I spent a couple years' working together with a friend every now and then on a
game+game engine in C#. We did get past the game engine phase because it was
kept simple (ECS + box2d and simple monogame 3d renderer) but we eventually
gave up because even though game logic was progressing swiftly assets were
just a pain in the ass.

Most low level engineers (as we are/were) underestimate the work it requires
to get a proper asset pipeline set up. You're never going to build a 3d game
if you can't load cheap 3rd party assets with their animations and materials.
And then the level designer which is basically just another game in your game.

We went with UE4 as a change of pace and man is it librating not to have to
worry about the limitations of your homebrew engine anymore. In UE4 literally
anything is possible (you have the full source after all) and its always less
work.

~~~
golergka
I guess, my question to the author should've been: why are you trying to write
a game engine? It's a completely different task than writing a good game, and
mostly conflicts with it.

~~~
crafn
Two reasons: Creative interests which make traditional game engines a hard
fit. I could make compromises to the design, but as I also have technical
interest in making game engines, it's a double win.

------
fizixer
> I have to choose between writing duplicated code, writing a code generator,
> or tedious macro stuff for generic code.

Code-generation all the way. Use an expressive language like
python/lua/tcl/lisp/scheme to work on a higher layer than C.

Two-language programming (one GC scripting, the other C) beats the heck out of
C++, in terms of best of both worlds: expressivity in higher layer,
performance in lower layer.

C++ has a dirty secret no one likes to talk about. Stroustrup himself was a
two-language programmer. C++ was C with classes where the classes were built
with unhygienic C macros. When he decided to show his work to "average joe
programmers" of the world, he turned it into one language (it turned out he
was not a very good language designer so the world has to live with it).

If you're working with C++ you are Stroustrup's average-joe customer.

If you're working with two-language programming you're Stroustrup himself
(even better cz you're using a higher language way better than the C macro
system)!

Other than that. You want superpowers? give your text-editor your C parser
(something similar to this [1]). Structured-editing can do amazing
productivity gains in C. This is something I'm still looking into (using some
vi/vi-clone, or emacs/emacs-clone, and pycparser) but I very excited about the
possibilities.

[1] [https://www.jetbrains.com/mps/](https://www.jetbrains.com/mps/)

~~~
gnarbarian
Script it out in python then replace the hot spots with c!

~~~
Franciscouzo
Or better yet, Lua!

~~~
gnarbarian
Why do you prefer lua?

------
dahart
> 5\. realize that I shouldn't be using some parts of C++ (exceptions, stdlib)

> 6\. start to ponder if I really need even the good parts of C++

This reads like wisdom and maturity to me; unfortunate, but not surprising,
that people are quick to judge.

Last game studio I worked at, we wouldn't have given up C++, but there were
frequent conversations about its pitfalls and complexity, and quite a few
rules and conventions recommending against, out outright prohibiting some C++
practices, exceptions, for example.

Before that, the last film studio I worked at, a bad experience with C++ led
them to chuck it (before I got there) and go object oriented C. I learned
their style of C and quite liked it. I missed operators and templates a bit,
and it felt a little verbose, but I came to really appreciate the simplicity
and explicitness.

Sounds like it wasn't an easy choice, but on a solo project that large you
have to prioritize what makes you feel the most productive in the long term,
and there are always tradeoffs.

~~~
na85
I don't use C++ for anything serious, can you explain what's wrong with
exceptions and the std lib?

~~~
spoiler
For exceptions: \- A bit unpredictable (hard to optimize)

\- Introduce a lot of exit points which are hard to find

\- They deviate from the "pay what you use," since they generate some extra
code

\- They can introduce some nasty performance penalties (I experienced this
myself a few yeas back, the compilers might be smarter these days, maybe)

About the stdlib: There's a "myth" that often times the stdlib/stl is slow and
doesn't do what you expect (unless you've thoroughly read the documentation,
which everyone should do anyway). I can't say I was personally affected by
this since I also use C++ for nothing too serious. I said "myth" because the
argument against the slowness it that this is an outdated notion.

~~~
exDM69
Most C++ compilers these days should have zero cost exception handling,
meaning that the non-exceptional path should be free. This works by making the
compiler add exception handler data to the executable file, ie. telling where
the catch() blocks are. When an exception is thrown, the stack trace is
analyzed and the appropriate catch handler is found by searching for the
return addresses in the exception handler data.

This can make C++ with exceptions faster than C with error checks because
there's no branches to check for every error condition. Using __builtin_expect
for marking the error conditions as unlikely may mitigate this issue.

~~~
jbb555
The cost is that you have to ensure that all your code is exception safe
unless you are extremely careful to ensure that exceptions are only thrown in
places you've expected and coded for.

Exception safe code is both difficult to write correctly and often has a
significant run time cost.

~~~
exDM69
Agreed on both accounts but the grandparent comment was talking about runtime
performance penalty, which is gone (for the non-exceptional path) in modern
implementations.

But yes: exception safety, even basic safety (don't leak resources or crash)
is difficult, let alone strong exception safety (no side effects if exception
occurs).

------
nly
A good article, but what disturbs me is that the author, while obviously aware
of relatively good C++ and programming practices, has somehow arrived in a
place where he discounts essentially all of C++s core competencies... like
claiming RAII is "far from optimal", that exception safety is "a constant
mental overhead", and that copy and move semantics involve writing "a lot of
code". These are fairly outrageous claims, and it all smells of total burnout,
and losing sight of the forest for the trees, to me.

I feel if the author refocused on his C++ basics instead of bemoaning lots of
peripheral crap (like OOP, and the unsuitability of the STL for game dev) he'd
reconsider some joy in C++ again.

~~~
crafn
>These are fairly outrageous claims, and it all smells of total burnout, and
losing sight of the forest for the trees, to me.

Maybe, I don't know. I have been a lot happier with C though, while still
writing some C++ code during the year.

~~~
lmm
I'm _happy_ when I'm writing C. It's only when I look back on a week of coding
and realise how little functionality I implemented that I realise it's a bad
idea.

------
girvo
I agree wholeheartedly with most of this post, but ended up coming to a
different conclusion to the author. I don't trust myself to write good,
maintable and safe C, so instead my semi-toy game engine has been (and is
being) authored in Nim instead, which I've found quite interesting. Writing
safe wrappers over C-libraries is a challenge in and of itself!

~~~
dikaiosune
Isn't Nim (and almost all of its standard library) garbage collected by
default? I've been very intrigued by Nim but it seems that while it has nice
native/C code generation, it opts into my least favorite element of "high-
level" languages.

~~~
girvo
It is, yes, however it's a bit different to most other GC-based languages in
that it's soft-realtime tracing GC. In addition, you can manage your memory
completely manually if you like, and in-fact thats how you interface with C
libraries, which I can say from experience works much nicer than I honestly
expected going in to it.

Excellent reference regarding Nim's GC and what it does differently here:
[http://nim-lang.org/docs/gc.html](http://nim-lang.org/docs/gc.html)

------
santaclaus
> When using OOP, like the idiomatic C++ coder does

Huh? Sure, you can go OO architecture astronaut in C++, but if that isn't a
good model for your problem, don't do it. I see more of a focus on generic
programming, anymore, in C++.

------
jbb555
Excellent article. I'm not sure I agree with all the points, but none of them
are stupid or necessarily wrong. It's a very constructive argument.

I've been thinking for a while that the problem with C++ is that 100 decisions
have been made both in the library & language and in "best practice" that all
individually are good, but the combined effect has been unfortunate.

I'm not quite getting from the article why you can't write in the C "subset"
of C++ and add in a few of the more helpful parts of C++ though.

~~~
loup-vaillant
> _I 'm not quite getting from the article why you can't write in the C
> "subset" of C++ and add in a few of the more helpful parts of C++ though._

I think this is because of C++ name mangling, which prevents the creation of a
quick and dirty reflection system. And maybe compilation times, which must be
higher since the compiler has to deal with all of C++, even if you don't.

------
flohofwoe
Completely agree, this is why most game developers use only a subset of C++ as
"C with classes", and at the end of that thought process some are going back
to C completely (I haven't made the jump yet though, but have been pondering
this for at least 2 years). What I still like about C++:

\- user-provided code called when an "object" goes out of scope

\- operator overloading sometimes makes sense

\- simple template-meta-programming sometimes makes sense (but could be
replaced with other sorts of code-generation)

3rd party libraries are usually a pain to integrate when they have a C++
interface, and usually simple when they are just a C header, and when they can
simply be dropped in as source into the project.

A good middle-ground is probably to build the building blocks in C, this way
they are way better reusable then writing C++ code, also across languages, and
tie the low-level buildings blocks together in whatever language one likes
(even interpreted languages).

[edit: formatting]

~~~
krisdol
Most are not writing their own engines anymore.

In this day of mobile and web gaming, indie developers everywhere, and game
engines like Unity and UE4 being so accessible, I think more game developers
are writing games in Java, JavaScript, C#, and other garbage collected
languages -- not to mention "visual programming" of Unity and UE4.

If you're writing a game engine in C/C++ today you're probably never going
beyond the desktop Windows platform.

~~~
taloft
Performance will be back if VR gets adopted. At 90 fps, you have around 11
milliseconds to update your game state and render views for each eye. That is
not much time. C#/unity and scripting languages will have a noticeable penalty
compared to native C code. Bloated engines will likely suffer as well.

------
Qantourisc
A lot of games run on Mono/.net Java etc. IIRC these languages have far more
overhead. (I could be wrong.) So unless you suspect you need >9000 fps OR you
are going to be doing a LOT of processing / complex game you might not need to
worry about it ?

~~~
jcranmer
The JVM can run pure Java code to within 2× of native code (although it has a
pretty weak vectorizer, so if you're getting vectorized speedups in native
code, Java won't get you that). However, calling a native function from Java
is a really high overhead call. Which means that the core engine likely can
run at essentially the same speed, but the graphics is going to be slower.

~~~
tormeh
Note that this is the default, standardized behavior. If you're willing to use
Oracle (and I think by extension OpenJDK)-specific features then there are
some functions with "unsafe" in the name that allows you to hand over memory
directly to native code, instead of copying it over. The default behaviour is
to copy all memory passed in and out of the JVM, so as to avoid native+java+GC
messing with the same memory area (potentially at the same time).

~~~
animal531
Same problem writing the engine in C#. You often run into memory and GC
problems that are a pain to work around.

------
hellofunk
As soon as I saw this headline, I knew there would be dozens of comments.

First of all, they are both great languages, no matter what anyone tries to
tell you.

I went through this same dilemma and, while I have great respect for C, I soon
realized that _my_ situation would be more productive with C++ and its tools
immediately available. For one thing, a lot of important libraries that are
common in games and graphics have C++ interfaces, so if you use C you are
asking of yourself to exclude some great tools out there, or, go through
significant steps to wrap some of them (which would still involve some C++
anyway).

------
rurban
I would look at one if those new type and memory safe languages which are more
pleasant to work with and usually faster than C/C++, esp. with concurrency.
Pony, felix, nim, Julia, Ocaml, elixir, rust.

------
andyjohnson0
This reminded me of Banished [1], a game developed by a single developer who
also wrote his own engine (though in C++). His development blog [2] goes into
quite a lot of technical detail.

[1]
[http://www.shiningrocksoftware.com/game/](http://www.shiningrocksoftware.com/game/)

[2] [http://www.shiningrocksoftware.com/](http://www.shiningrocksoftware.com/)

------
jeffdavis
I can't help but think the author would benefit from some of the philosophy of
James Hague (a game programmer):

[http://prog21.dadgum.com/](http://prog21.dadgum.com/)

Don't focus too much on technology, disconnected from what people (including
you) might want to actually use. Otherwise you will not get the real
inspirations -- even purely technical inspirations -- that come from something
that you intend to use.

~~~
crafn
I get where that comes from. I surely did have the disconnection some years
back, but think I'm on a better track now. Thanks for the link.

------
Apocryphon
Has anyone attempted using Objective-C for game development outside of iOS
gaming? It'd be interesting using it as an OO language substitute for C++.

~~~
gaze
No. It has the speed of smalltalk and the type safety of C.

~~~
iainmerrick
That's a nice soundbite, but not really fair.

Modern Smalltalk-style languages can be fast. Look at Javascript! And in
Obj-C, you can drop down to plain C when you need the speed.

It's possible to get your types mixed up when using non-generic collections,
and that will throw an exception at runtime. No different from Go or Python.

In terms of memory safety, it's a step up from C if you use ARC, as all your
object lifetimes are managed automatically. You can still get memory
corruption if you're careless with arrays, but it's not really an issue with
objects.

------
jongraehl
Every one of his complaints has a good solution, albeit some not widely known.
Except compile time, single source file or otherwise - the compiler is using
lots of smarts and lots of library headers on your behalf.

That said, author has done a good job explaining his thought process in taking
the rewarding-at-every-step path, given he's not a C++-wrangling junkie.

------
jbb555
Are there any other sources of information on "modern C"? I'm thinking
particualrly on how to handle memory allocations well and safely, and how to
write clean containers and algorithms. It's been a long time since I wrote
pure C and I'd like to try it again!

------
hellofunk
Wow, I had to change the brightness and contrast setting on my monitor just to
read this article. What is the strategy behind this darkish font against black
background? I wish more websites geared towards a reading audience actually
provided a nice reading experience.

------
andrewchambers
I have recently started using myrddin (compiler here
[https://github.com/oridb/mc](https://github.com/oridb/mc) ) as a c
replacement.

It is still changing fast but I think it could be great for writing games in
the future.

------
alkonaut
> are going somewhat off already by definition, as they're focusing primarily
> on safety, which is not the focus for most game code.

Depends on what you consider safety to be. A game engine that doesn't deadlock
and doesn't crash should definitely be high priority!

------
shmerl
Why not Rust for example? If I'd be making an engine, I'd tried that.

~~~
dikaiosune
"Safety-enforcing languages like Rust are going somewhat off already by
definition, as they're focusing primarily on safety, which is not the focus
for most game code."

I don't really agree with this assessment (I think rust's "safety guarantees"
really amount to amazing compile time programmer assistance), but that's their
stated reason.

~~~
pjmlp
What many that issue that kind of statements forget, is that safety is also a
means to keep the game experience clean.

Exploiting buffer overflows, stack corruptions and friends is how we get to
earn extra lifes, bypass hard levels, get extra ammunition and so on.

~~~
dikaiosune
Are you saying those are good things or bad things in the context of games? As
I commented elsewhere, it's not that I don't think that Rust's safety isn't
important, but it's not the only worthwhile element of the language and I
think it's good to recognize that its safety guarantees can eliminate many
"non-safety" bugs in many programs.

~~~
pjmlp
I am saying they are bad things, then again game developers aren't known for
worrying 1s about safety anyway, specially if that implies 1ms less, even if
that isn't an issue for the game being developed.

~~~
shmerl
The major benefit is simply avoiding all kind of crashes which plague many
games.

~~~
pjmlp
That is another thing that sadly many game developers usually don't care that
much, given time to market.

~~~
shmerl
Which is surprising, since games are very much human faced, and those crashes
is what's considered reducing the value quite a bit. So using something like
Rust should be a big boon for game developers. The only issue is that some
things will still remain in the unsafe area (i.e. interfacing with graphics
backend and such), but at least the code that developers control can be safer.

------
seibelj
Thank you for this very detailed and interesting write up.

------
vskarine
what are your thoughts on using D? I find it to be a better C++ and a step up
from C.

------
nine_k
I'd hazard to offer Rust :)

Someone has to.

~~~
Rusky
The author does mention Rust:

> New and hip GC'd languages don't care about the priorities efficient game
> engine code has. Safety-enforcing languages like Rust are going somewhat off
> already by definition, as they're focusing primarily on safety, which is not
> the focus for most game code.

However, I disagree with this. Rust does enforce safety, but once you have a
feel for how the borrow checker works (which isn't hard at all coming from C
or C++), it fades into the background. The real benefits of Rust for games are
the build system, the module system, affine/linear types, and all the various
syntactic features like pattern matching and expression-based control
structures that make it way less crufty to read and write than C or C++.

Rust's biggest weakness for game dev (again) isn't the enforced safety, but
the still-growing ecosystem. There's a few really good low-level libraries
(Glium, for example), but if you stray beyond them it turns into a nightmare
of writing your own FFI definitions and unsafe glue code.

~~~
dllthomas
Right. The last ultra-performance-oriented work I did (in C) I'd have loved
affine types and a borrow checker. Used right, these kinds of tools not only
don't get in the way (as you note) but prove tremendously useful when you need
to refactor.

