PezzaDev

Automated testing is hard to justify for games because you are not simply finishing features and moving on. You are constantly experimenting. Throwing out features and ideas and reworking them is part of the creative process. Automated testing adds overhead to iteration and isn't free, so you have to be very selective. At the end of the day it is more important for the game to be fun than it is stable.

You made me realise that term "dumb code" isn't exactly what I mean. I want to advocate writing code that is very easy to statically understand. You should be able to look a piece of code without needing to read too much around it to understand what it is doing. One of the best ways of doing this in my experience is keeping things simple (or "dumb" as I put it earlier). Using simple abstractions, keeping code organised and avoiding global state also help in this regard.

No coding approach will ever solve an issue caused by a lack of discipline.

And everyone wishes they hadn't :P Even modders that use Lua have to write code that avoids allocations, caching and reusing all the objects they can. I can't stress enough how much time is spent on optimising code to avoid GC pauses. The main goal of my C# coding style is avoiding unnecessary allocations at all costs. I'm not exaggerating.

I'd love to try Golang, but as a game developer, the gc makes it a no go due to perf. I begrudgingly accept C# due to unity. GC is a different topic altogether, but has also always been a pain. You end writing code to avoid allocations, which at that point you ask "Why am I not just writing C++?" I also discovered GC makes bad programmers worse by allowing them not to care about ownership, enabling them to develop systems in an adhoc way. Some programmers need a segfault screaming at them to make them realise they are writing terrible code.

After years of experience writing code for games, I find that the dumbest code is the best code. It doesn't matter if it's C# or C++, whenever I've used something like reactive extensions or template metaprogramming, it has been a terrible mistake every single time. Make your code simple, dumb and verbose all the time. Avoid using any complex abstractions or any overcomplicated syntactic sugar and you'll have a codebase that anyone can jump into and quickly be able to add features without introducing bugs (at least less likely). This matters more than anything else.

Try bluring your vision or moving further away from your screen.

What are the advantages of this other than showing the language is competent enough that you can write a compiler for itself? Would it be better to keep a compiler written in a highly portable language such as c? Genuinely curious.

I feel zig is now experiencing feature creep now too sadly. Async and await and coroutines are being added to it, because it's the new-ish hotness I guess? Stopped paying attention to the language after that. I was hoping for a more streamlined language.

It frustrates me too. I'm always on the look out for languages that implement modern performance approaches into their design. I'd love to see a language that focuses on data orientated design, auto-vectorisation and possibly something like reference capabilities for concurrent programming. That language would truly be "blazingly fast".

AOT (ahead of time) is your code is turned into machine code before you run it.

JIT (just in time) is your code turning into into machine code as you run it. Machine code is what your CPU directly processes, so it can be very fast.

AOT languages can use more expensive techniques to make super optimised machine code since the cost is upfront when compiling the code, not when running it. But JIT languages can have features that exploit the fact that machine code is made on the fly.

AOT programming languages: C++, C, Rust

JIT programming languages: C#, Javascript, Java

After seeing callbacks cause a lot of "hard to debug" scenarios for me and for others, I'm starting to believe they are gotos in disguise.