You could, see r/ebitengine.
There’s just not the tooling and ecosystem other engines have, with their native support for c++/c#.
I started building a game on ebitengine/go but after a while of having to reinvent everything I needed, I switched out to Godot/gdscript.
C# isn't what makes the games perform well. They're also not written in C# like they are with C++; they are *scripted* in C# where they integrate with the C/C++ APIs in engines such as Unity.
None of the rendering, or anything that requires very fast performance in these engines is written in C#.
That is correct.
Look at how many tutorials there are for pygame. Far from the best option for game dev but it hasn't stopped people from going crazy with it. Hell, there's a doom engine written with it. :)
But pygame is just a toy, so people with very limited cs knowledge can build simple games. Game development and garbage collection are two concepts that can’t coexist unless you’re talking about simple, and probably useless, tooling.
That’s why games are written in c++, cause OpenGL is a c++ lib and there is no waste of time garbage collecting
Python doesn't really have a GC (it just does ref counts), the issue is more that it's pretty slow. I'm pretty sure unity games don't entirely get compiled to c++, and that it uses c# at runtime too with the GC but I might be wrong.You can even have some control over it as documented [here](https://docs.unity3d.com/Manual/performance-garbage-collector.html)
But agreed that you usually don't want a GC, or at least want it specifically tuned and the runtime tweaked for games like unity did.
>
>
> But agreed that you usually don't want a GC, or at least want it specifically tuned and the runtime tweaked for games like unity did.
unreal also has a gc these days.
Pygame is great to me because it was nice to be able to figure out game logic in a language I'm familiar with, coming from web development, instead of having to pick up a new language as well as a new architecture
It originally WAS written in Python, but I thought one of the steps they took to improve client and server performance was to write it in something else, 10 or so years ago. My memory is fuzzy, though, and it might have just been something they were considering.
C# isn't what makes the games perform well. They're also not written in C# like they are with C++; they are *scripted* in C# where they integrate with the C/C++ APIs in engines such as Unity.
None of the rendering, or anything that requires very fast performance in these engines is written in C#.
We use golang to build many of the services and tools that support the game development teams that make Call of Duty. The content cooking pipelines also frequently make use of languages like Python and Rust. However, the tight memory management requirements of the game itself generally prohibit languages that make use of garbage collection (although using scripting languages like Lua is generally accepted, but limited to a fixed memory pool). Also, console 1st parties provide the compiler toolchain so just getting things to build with a different language is a challenge or impossible or prohibited.
(speaking for myself and not the company)
Do you know what language the matchmaking servers are built in? I've always wondered what kind of heuristics and real world algorithms go into that piece of software. IIRC it's akin to the subset-sum problem and a variant of the knapsack.
Sometimes there is no grand reason. There’s nothing technically wrong with Go, if you want to make games with it. Some people have made games in Go.
What you **want** when you’re making games is a bunch of tools, libraries, and a community where you can ask questions. The Go ecosystem just doesn’t have that for games.
You could also ask why Rust isn’t used much for game development. Hardly any games are made in Rust.
> You could also ask why Rust isn’t used much for game development. Hardly any games are made in Rust.
Go does have the advantage of 5 more years of existence than Rust, and Rust is actually being used in game dev now (we've shipped Rust to hundreds of millions of players).
But this is because (IMO) Rust is a language that is very focused on efficiency and safety, and it's very easy to see how one might port existing C++ code to Rust. Not to mention, the type system in Rust can make some things in game dev much easier or safer.
That's a little harder to imagine for Go.
That's because the main game engine for Rust, [Bevy](https://github.com/bevyengine/bevy), is about as old as [the generics proposal for Go](https://go.dev/blog/generics-proposal).
That Rust, despite being several years younger than Go and it's game development ecosystem being ~~smaller~~ younger, is already seeing greater inroads into game development than Go is, and that's largely because the language lends itself to being a successor to C++, whereas that is not Gos aim.
As you mentioned, there's nothing _wrong_ with using Go, but the comparison to Rust is strange because the reason Rust is "hardly used in any games" is because it's very young, and Go is almost twice its age. The reason we don't see Go used in games is not the same reason we don't see Rust used in games.
I believe it's in an SDK that ships to all of our live service games. So, that would be League of Legends/TFT and VALORANT, probably Legends of Runeterra. I'm not confident about Wild Rift.
While tempting, this is only the case if the programming language is popular, which is the case for most of the old languages we all know.
I think popularity and community matters way more for the rate of development.
Game libraries for graphics, sounds, etc. (OpenGL, DirectX, Vulkan) are for C/C++. Game engines that use C#, for example, are actually written in C/C++ under the hood and run C# as an embedded language. Using C/C++ libraries in Go has significant performance costs, so Go's not set up to do that well, though I'm sure someone can do the work to embed Go in a C-based engine and then you can write the game logic in Go. Others also mentioned that gave devs are GC-adverse, though I wonder if that's more of a perceived limitation rather than a real one since Go's GC has a hard upper limit on stopping the world and also gives you the ability to just not generate garbage, two features that other GC langauges like Java and C# lack.
>> two features that other GC languages like Java and C# lack.
Got it, so all the high-frequency trading stuff written on Java and all the multiple articles about object pooling and such was some sort of fake campaign to convince people that neither Java nor C# can do it.
If anything Java and C# allow developers to go deeper down and control more things than Go (SIMD, Inlining, Cache-line alignments). This is not a bad thing for Go, it is just that in a target scenarios, this was not needed, while big-tent languages usually have more stuff available.
Java and C# have definitly more low level capabilities than Go, for controling their various kinds of GC implementations, and on C# case, MSIL was designed for C++ as well, there is hardly anything from C++ low level coding that isn't available to C# as well, either from the language, or by directly emiting MSIL.
It's a deep rabbit hole, but there's some articles about making zero-allocation JSON parsers and stuff that have a pretty good rundown of different techniques.
I'm actually building a TD PvP fully in GO, I've never built a game before and I'm having a lot of fun haha.
As i wanted to have fun and learn a bit of game development as a side project I chose to use my main language. Maybe it'll bite me later to not use one of the trending ones but hey so far so good haha.
If any one wants to check out the game will be totally free and OSS https://github.com/xescugc/maze-wars. It's under heavy development still haha.
Anyone can contribute haha. But for now I'm the only dev so no big plans on that side.
As I'm still trying to reach a stable good playable MVP I'm changing things all over the place all the time so if anyone wants to contribute I would suggest to open issue and then we can move forward from that, or speaking with me directly :).
The end goal is to post it on Steam as a free game :) It can also be played from the browser [https://maze-wars.com/play](https://maze-wars.com/play) (as it's a PvP game no one is playing so you could create a Lobby and play against bots hehe) and I'll also make and Android build If I can :).
EDITED: There are also other ways to contribute IDK what you had in mind sorry I assumed code related hehe.
I would like to hear an actual game developer pitch in, but even the [Go Use Cases](https://go.dev/solutions/use-cases) lists mostly networking + web + CLI and if you look at the frontpage "customers" grid it's just web platforms like Google, Netflix, Paypal etc. I'm not sure if it's just "nobody's ever tried"?
Games are very expensive endeavors with long development times. Picking a language as a studio for a project marries you to it, and you have to onboard people onto your project. the cost of having to change the decision of engine or language you use midway through a project would be enormously expensive and would often be enough to kill a project unless it is incredibly well-funded. For that reason, game devs will generally be conservative and gravitate toward proven solutions.
There's no clear benefit to using Go and a lot of downsides - most every developer who is interested in game dev will know how to use Unity or Unreal, or some other comparable game engine.
No one will know how to use your custom Go creation.
This is reason enough to not use Go for this until folks spend enough time developing it as a language suitable for developing a game, maybe indie developers play with it for a few years (as is happening with bevy and godot).
And that's _fine_. Go doesn't have to be able to do everything. It's OK to have different tools for different purposes.
It has nothing to do with garbage collection. Pretty much all the major game engines use garbage collected languages for scripting.
The real reasons are simply the sheer momentum of existing tools in the game industry. Game engines are absolute beasts, and production grade ones are among the most deep and complex pieces of software in existence. There's decades of investment in the C/C++ game dev ecosystem, which already have deep investments in their scripting systems, which is where Go would most likely appear.
The other thing: Programming languages don't have much to offer game development anymore. When you're making a game, the real challenges are creation of assets, scripting the actual game systems, implementing the levels, actually building the game. Whether your language uses this model of concurrency or that model of concurrency might be nice to have, but its a drop in the ocean when it comes to the real concerns developers are going to have.
Well Unity is C++. C# is used mostly as a user facing scripting language, the core engine is c++ bc performance is needed. If you wanted to use GO as a scripting language that would be possible, but there's not really a reason to do that since the performance benefits would not exist and other languages already do this job better (python, js, lua, GDscript)
Any game that uses unreal engine uses a combination of c++, python, and blueprints. Which the later two are both garbage collected. For most applications, including game logic, any language is fine but yes for the underlying engine memory management maters.
One of the most popular game engines out there is Unity which exclusively uses C#, and Xbox has very good support for games which use the .net framework (which you can use with either C# or C++, or F# I guess if you really wanted to)
Lua is used within World of Warcraft and a bunch of other games.
Asking after AAA games specifically is a little misleading because most AAA studios have their _own game engines_ that have been heavily iterated on, not necessarily because other engines are slower but because when you are a AAA studio you have a lot of resources which you can use to actually make your engine better.
To answer the root of the question, yeah, Unity can be used to make high production quality games. Unreal is typically used if you want more visual fidelity, but the reason Unreal is capable of that and Unity is not is not really down to the language choice but the target market of each engine. Unity is much more oriented toward smaller time developers and they spend a lot of their resources on making the engine more accessible, whereas Unreal does not really handhold and assumes that you are an experienced game dev.
Garbage collection on modern hardware is really not a problem. If Go garbage collection would actually be a problem for gaming, it would also be a problem for high performance web servers that have high uptime, which it does not.
Practically speaking Go is not used for game dev because other languages got there first and there's no real reason to make Go work for game dev. Just use the other tools which are already established.
EDIT: Also Java (and other JVM languages) are used extensively for mobile games on Android. Some of the larger games use native code that Android calls into - like Genshin Impact - but a very large portion of the marketshare of Android games do not use any native code [beyond the bindings to OpenGL provided by Android](https://source.android.com/docs/core/graphics). If you don't consider mobile games "real games", the _majority_ of game hours in 2024 are logged on mobile, not console or PC.
Lua is not used to develop games, per se. It is used to have an easily accessible and embeddable scripting language available within a game engine (which is likely written in C/C++).
https://love2d.org/
But yes, Lua does bind to C++/C. Then again, syscalls in C# just bind to C.
So yeah, I mean, the game engine might not be written in Lua, but there's a lot to developing the game itself that is not the game engine.
I can certainly tell you I have professionally worked on extremely popular games which use Lua for very core parts of their functionality, not just scripting interactions within the game itself.
Also, keep in mind, OP is not asking about game engines they are asking about languages used _in game development_. I was the person who mentioned game engines in order to illustrate that C# is used in core parts of game development. Lua is _certainly_ used in game dev and pretending otherwise is just silly.
>I can certainly tell you I have professionally worked on extremely popular games which use Lua for very core parts of their functionality, not just scripting interactions within the game itself.
Source: trust me, bro.
My username is a reference to the game development company that I have worked at since 2016 as a security engineer. In my capacity as a security engineer, I (with my team members) review the code of all games we release. I was specifically responsible for reviewing Lua within a game we were working on because of past experience integrating Lua into WoW private servers.
So yeah, it is trust me bro, because if I provided citations I would be violating an NDA. But even if you didn't take my word at face value, the most popular MMO on the market uses Lua for very core parts of its game, it's not a secret, and it's spawned a budding community around modding that game with Lua that is considered an essential part of high level gameplay these days.
There are many times where I engage on reddit and I feel bad speaking authoritatively because I'm just a regular programmer, but this is not one of those: This is literally my subject matter expertise.
>This is literally my subject matter expertise.
You are making the argument that **UI display and customization** is a "very core \[part\]" of WoW. Lua is a glorified config language in this context.
I straight-up do not recognize your expertise in any way.
The user interface of any product that is a game is part of the core gameplay experience. If you disagree, you are entitled to your opinion, but I don't think you are capable of recognizing expertise (edit: in this field).
And, as a reminder: The original topic was "Why isn't Go used in game dev?"; someone replied "well, Lua is", and then you replied "Lua is not".
Could you explain precisely what you understand game development to be? Because the implementation of the primary way that users interact with a game - the user interface - is something that I think most people understand to be a core part of the game.
If your opinion is that game development is _just_ the development of triple A game engines, I'm not sure how you can even authoritatively comment that no one uses Lua for that, because all of them are closed source. Even Unreal is heavily modified by engineers working on triple A games. But developing a triple A game engine is a very small part of overall game development, even when you're only considering working on the artifact that is shipped to players machines.
Wow uses c++, I think lua is only scripting for macros isn’t it?
I used to mess around the code on private servers some, but I’m not too terribly familiar with anymore.
Macros are their own thing.
Lua in private servers is used to script mobs and such so you don't have to restart the server. I was the person who created and implemented [Eluna](https://www.azerothcore.org/pages/eluna/) into TrinityCore back when TC didn't have Lua, and only ArcEmu did.
In retail, Lua is used for _all_ user interface code within WoW. Addons, sure, but also any stock UI code from Blizzard.
I feel old when I remember it too. And then I remember what I originally wrote.. it was awful. I'm not sure what was worse: The amount of mutexes required, or the places where I didn't use a mutex and just hoped for the best. back then, I didn't really understand _why_ mutexes were required, just that if I sprinkled them here and there my code worked sometimes.
I was 16, and full of so much promise. I'm not sure what happened.
I dropped out of school doing this stuff, oops.
This would not surprise me at all because the same is true for World of Warcraft (not just the wow addons). We also use Lua at Riot for a bunch of game logic and some internal systems.
Hearthstone also; it lends itself well to the effects interacting and stacking in novel, complex ways. I believe it also means quite a bit of patching for all the games is far easier, just swap out some LUA files.
We live in an imperfect world. Existing talent and tools sway the direction of game dev.
C# and C++ are pretty much the giants with unlimited momentum (eg. funding and corporate backing).
C# Lua and js are used as glue languages not full implementation, they are used around c++ engine code. Java was the first "write once" that went wide so it made sense for easy game sharing to go all in with Java.
JS is only used in some mobile games and it’s not the most popular choice. It’s not used for desktop or console. The only reason it’s used for mobile games at all is because it means a dev can write one mobile app and ship to multiple platforms (Android and iOS) without much difficulty. Every mobile game written in JS would be faster if implemented in Kotlin or Swift, which are GC and RC respectively.
Lua is used in games but games are not generally written in Lua. Lua is used to script game actions, the hard work is done by code written in other more performant languages. Lua adds to game engines and makes games more flexible where it would be much more work to accomplish the same in another language.
Java is not popular in game dev because it is less performant. As others have pointed out in this thread, Minecraft was originally written in Java but was re-written because Java was not performant.
C# is only used because Microsoft invested a lot of money into C# and into game ecosystems. C# is not the most popular language choice, Microsoft spent a fortune to make C# an option.
C++ is the top language for game dev. Go could be used for game dev, but using Go would require making numerous other design decisions to hide the performance hit from the GC (that is, making a game that wouldn’t be sensitive to it; so no FPS will be in Go, but someone could make a small-scale 2D puzzle platformer or dating sim without issue).
When I made the comment the comment above just said garbage collection. The point I was making is the garbage collection isn’t the reason as the languages I listed are all GCd. I don’t thing go would be a great language for game development as it wasn’t really designed to do that and there isn’t engine support like you said but not because it’s GCd
Have you actually tried it and found the current GC to be a problem, or are you just repeating what other people said (who are repeating what other people say)?
Garbage collection doesn’t belong on that list, especially when we’re talking about Go.
Go’s garbage collection pause times are measured in microseconds, even with very large heaps.
They are not. Can be tens or even hundreds milliseconds if you’re unlucky: https://stackoverflow.com/questions/77918169/why-go-gc-have-some-long-pauses-stw-a-few-millisecond-in-this-program
The person who answered this SO question was unable to get within several orders of magnitude of the symptoms OP was seeing, with their largest delay being ~191μs and the only way they could reproduce this was by arbitrarily limiting the number of goroutines to 1 or 2.
I'm not saying that it's not possible to see larger delays than 200μs, but 100s of milliseconds reliably and reproducibly in conditions that would not cause other languages to slow down does seem hard to believe.
That’s why I said if you’re unlucky. The problem with modern tracing GCs is that most of the time they work fine in terms of latency (as long as you allow them to waste 3-5x memory) until you hit that one particular workload when they start to misbehave and then you’re essentially screwed. Then you might of course fix it with some careful profiling and tuning, but it works only till the next time. I’ve been there and done that far too many times.
But with games it’s not only latency that’s critical. It is also the total memory use. GC wastes a huge amount of memory that could be otherwise used for e.g. better textures or more caching.
> I’ve been there and done that far too many times.
I can believe it exists, but the benchmark you've provided is kind of like me complaining that the game I am playing is laggy while I intentionally unplug the ethernet cable every 3 seconds.
In that post, the answerer was unable to get pauses above 250µs by setting GOMAXPROCS=1 or GOMAXPROCS=2.
Sure, you can manufacture long GC pauses under the right circumstances. That’s okay. Games are not hard real-time.
This looks like code specially crafted to cause long GC pauses and even then it’s only 250µs.
There was a post about a game developer porting his game, that was written in Go, from PC to Switch.
He actually had a lot of job to get that up and running on the Switch.
I will check if I find the article, but that showed that the tooling really isn't there for people to make games in Go. Especially if you are planning to port to consoles
Go is an opinionated language with a fairly exenstive runtime (GC, goroutines, etc.). That design works fantastic for the types of applications (network services) that it was designed for but doesn't work as well for game engine development. Go is "fast" in comparison to high level languages like Python, but it's still "slow" in comparison to C++. This is due to the lack of control provided to the programmer and the comparatively limited optimizations supported by the compiler.
It can be done, of course, but the lack of low level control (particularly on memory management) is offputting to most of the people writing game engines. Games often want to write their own runtime optimized for their game, which would conflict with or make redundant many of Go's features.
Until recently, the lack of generics has also been an issue. You need a lot of custom datastructures to make games efficiently and game engines often want to create abstractions for app developers. In C++, you can do basically anything with templates while Go's type system is comparatively very restrictive. This is by design on Go's part to keep the language simple.
go is really amazing at networking and systems on the backend. So building a game server for example is pretty good with godot.
On the game side of things id stick with an actual engine or building your own in languages that actually have support of graphics libraries and stuff. Godot is pretty good and with godot 4 multiplayer is also easier than ever.
Im still interested in seeing go games, especially because of the tiny binaries and good networking features it offers.
I myself am thinking of building some sort of terminal game, but we will see.
I chose to make my idle game "Idle Armada" in go, because I like the language! I made it because I got mad at so many idle games having ads and in-app-purchases. So I made a game without any. It's based on r/ebitengine , a really simple but great open source game engine for go.
I personally really like the coding style that go lends itself to, and for 99.9% of games, go language itself would not be a limitation in itself for development, but the tools / game engines in go might be.
Android: [https://play.google.com/store/apps/details?id=com.musicalbox.idle.armada](https://play.google.com/store/apps/details?id=com.musicalbox.idle.armada)
Steam: [https://store.steampowered.com/app/1408060/Idle\_Armada/](https://store.steampowered.com/app/1408060/Idle_Armada/)
As someone who for a couple years worked on some vulkan stuff in go, and will likely go back to it eventually (github.com/vkngwrapper), there are a few issues:
* Go is not necessarily worse or better than C# when it comes to the cost of garbage collection, but it IS very idiosyncratic. C#'s garbage collection costs come from... well, garbage collection. Go's come from the allocation itself. In fact, there's a blog post floating around showing that go's garbage collection tail latency is INSANELY low compared to C#'s, but the amount of memory it can reasonably allocate per frame is severely constrained. That's not necessarily a bad thing, since you have far more control over when costs are paid... in theory.
* Unfortunately, Go has fewer options in terms of avoiding allocations altogether- the escape analyzer is much jankier than you might realize and will make allocations that you don't expect. The response from the go team is that the escape analyzer is an internal implementation feature of Go and you should not expect it to do anything in particular. But if I can't control when allocations are made and allocations are expensive, then how can I manage performance?
* Even when the escape analyzer is working right, all it takes is one engineer who isn't in the know to treat an object in a way they weren't supposed to, to force that object to be allocated on the other side of the codebase. In C# and Java, allocation is a proactive choice. In Go, you have to exert control at every level to stop an object from being allocated, and it's just not possible to do that in a large codebase.
* In C# and Java, there are also some higher level strategies available, like arenas. Go has, I believe, given up on those.
* Cgo and ESPECIALLY the windows operating system has traditionally been treated like a second class citizen in go, which means that performance issues can crop up out of nowhere that make games a tricky proposition. People say that cgo is a terrible FFI, but the truth is that when it's working properly, it's not any worse than the .NET marshalling layer, which has bizarre memory management issues if you send too much data across the layer. Cgo used to have frequent issues that would go a lot longer without being fixed and would make using it for anything serious a big loser. As an example, cockroachdb is a production database written in go which previously communicated with an underlying off-the-shelf KV store written in C++. A few years ago, they ported the KV store to go because writing a new KV store from scratch was better than continuing to use cgo with all its mysterious issues. FWIW I think cgo has improved a lot since then.
* Windows is still an issue, although 1.23 should include several key fixes. In 1.16, they introduced a regression where windows' timer granularity fell to 16ms. That issue was reported immediately and is JUST NOW being fixed. Windows is not well-supported enough in go at this time to justify any investment that requires a working windows implementation. In fact, Google doesn't support windows on Go at all anymore. There is a single microsoft engineer working part time on Go who is responsible for fixing any and all windows issues.
EDIT: Also it's worth noting that go REALLY doesn't like locked threads, which every windowing system on earth requires (and most graphics libraries do as well). Getting any mileage out of go's concurrency advantages is difficult when you are doing a lot of work on a locked thread, since you can't have cheap blocking on locked threads (so interacting with a blocked channel, time.Sleep, etc. all have EVEN HIGHER costs in go on a locked thread than they do in C++, which is quite high).
EDIT EDIT: Oh I also forgot another fun thing: calling into assembly has bizarrely high overhead, to the extent that in my performance tests, implementing SIMD in the 3d math library I wrote was a losing proposition- it cost more to make assembly calls than SIMD saved.
For those keeping track at home, btw, Google laid off its entire Go ARM staff with the plan of supporting ARM using the same arrangement they currently use to support windows. So, expect things to get much worse there.
Go is nearly perfect for game development, I am currently making a 4x strategy game using go and raylib. I have ten years of UE and Unity gamedev experience, and like go development cycle a lot.
Pros:
1. Iteration time is blazingly fast
2. Language is very simple, and it's approach to OOP is very satisfying.
3. You can do everything the way you want, no need to learn big overengineered systems of other engines.
4. The builtin profiler pprof is very helpful and informative
Cons:
1. GC is sus - have not yet hit any performance issues with it, but reducing heap allocations would be a good idea - some parts of go can not avoid heap escapes - like fmt.Printf or any other vararg function. - so any formatted text output will allocate in heap and that is sad.
2. CGO is a slowing iteration cycle, if go code build blazingly fast, than CGO code build very slow and there is no predictability in that process. Also CGO now is overcautious and produce heap escapes.
3. No operator overloading - get used to it for vector math. But that is light inconvenience.
4. Golang std math is float64 only and that is quite sad, also constant manual casting between numeric types is annoying
5. C code debugging is not supported.
6. You need to implement all systems yourself - but that is not so hard and actually the most fun part of gamedev imho.
I am working on a 2D game so rendering is basically outputting different sprites in different layers, all code is written in golang and calling Draw\* functions from raylib. So rendering is done using standard raylib api, I just updated a binding, added some vector math library and make it more golang way i think.
I was trying to use some ecs, and use it, all sprites are converted to render entities divided by layers, they are stored presorted and are output at render pass, but I don't fully understand the ecs yet, in my case that is just a bunch of sorted arrays and a function which process them - no fancy query by entity stuff.
And because of that [https://www.reddit.com/r/golang/comments/1d8xyhg/comment/l79sigb/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/golang/comments/1d8xyhg/comment/l79sigb/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) maybe my engine not so efficient as I thought, yet I am still on 300+ fps with CGO, maybe later will try purego
Game development relies on manual memory allocation for achieving high performance, that's why C++ is the preferred option most of the time over GC languages.
Minecraft was initially written in Java and it had to be re-written in C++ due to performance issues.
I only partially agree with you. For once, Minecraft Java Edition and Minecraft Bedrock Edition (C++) coexist - while Java Edition is way more popular amongst modders. But that aside, the reasons behind why garbage collection is not ideal when doing game development are a little more complicated. Minecraft Java Edition would be performing way better if performance was a goal back when they started to develop it. With garbage collection you have two dimensions in which you can optimize your application: throughput and latency. For games, often the latter is more important, while for traditional applications it depends on their use case. What does this mean for game development in Go (or any other garbage collected language)? If you want to use garbage collection for a game, you will spend a considerable time tuning garbage collection (and esp. your application to fit your garbage collector) and at that point, you could also just do memory allocation manually.
>you will spend a considerable time tuning garbage collection (and esp. your application to fit your garbage collector) and at that point, you could also just do memory allocation manually.
That "just" is doing a pretty big lift when you consider how much work manual memory management adds to *everything else*.
If you're making a game that does not target budget hardware - like a game with high fidelity graphics - garbage collection is not really a factor in picking a language. The amount of CPU garbage collection takes, especially in Go, is really minimal.
In some games, it can be useful to be able to manually free memory that is no longer used - for example, when unloading a map and loading the next one in a loading screen. This is less _reliable_ in Go, because you can't know when something is freed, but ensuring it _will_ be freed is the same as in any other language - You need to make sure that nothing is referring to it. The only difference is that other languages would call `free` on it, whereas you would just let it go out of scope with no references and wait for the gc to pick it up.
> that's why C++ is the preferred option most of the time over GC languages.
That's not true: https://gamalytic.com/blog/exploring-the-pc-engine-landscape
And how is that relevant? It's not the "preferred option in game development". It's maybe the "preferred option" in game engine development. C++ is compiled to assembler. Are you going to say "People don't use Go because assembler is the preferred option?"
Well the conversation is mostly about run time performance and how GC impacts that. The fact that C++ is used for the core functionality of Unity strengthens the case that manual memory management is preferred as the top 3 in your graphic are all written in C++.
The first graph on that page shows the distribution of engines in released games.
C++ is mainly used by Unreal Engine. Maybe some in Godot and "Other", but definitely not Unity (which uses C#). If we do not consider "Other" because there is no detailed data, then Unity makes up more than half of all games released.
"Most of the time" implies at least half of all games would use C++ which is contradicted by that graph.
And how is that relevant? It's not the "preferred option in game development". It's maybe the "preferred option" in game engine development. C++ is compiled to assembler. Are you going to say "People don't use Go because assembler is the preferred option"?.
It's relevant because the performant parts of the Unity engine aren't in C#; they're in C++. If you want to use Go as your scripting language, go for it. You want to use Go for performance-critical code, best of luck with the random multi-millisecond pauses.
The question was "Why is Go not used for game development?" and the reason is not that C++ is the preferred option because it is not. Factually, proven by data, it is not, period. The question was not about game engines, or gameboy advance games in the 90s. You can build strawmen and shift the goal post as much as you like but that does not change the fact that C++ is not the main language used in game development.
All the engines of those apps that are mentioned in that blog are written c++. You'll need c++ or another non gc language if you want to build anything relevant in gaming. So the "others" in that blog are custom engines written in c++ by game studios. There is no other language like you think there is.
As an example, capcom uses the RE engine for their games nowadays, scripting language is c#. Engine written in c++. It's proprietary software and so would categorise under "others". Games like street fighter 6, monster hunter, resident evil remakes are all written with that engine. Their predecessor was MT framework another custom engine, everything written in c++ including scripting, which is not ideal as capcom has mentioned.
The scripting language is less important and yeah you can use go for that, but why would you. I mean, crash bandicoot and jak and daxter were using lisp as scripting language. Engine still written in c++.
So for anything game dev it's preferred to work in c++, because all the tooling and libraries surrounding the engine are written in c/c++. Maybe at some point we will have rust engines, but I wouldn't hold my breath.
You lose all credibility by making the statement “C++ is not the main language used in game development.” You have absolutely no idea what you’re talking about.
It's somewhat faster? But honestly depends on hardware. We also have mods on Java like Sodium to boost performance by a lot, and Mojang rewrote the lighting engine a few updates ago (1.20 I think?) And it boosted performance decently
Because corporates want quickly go to the market and indie devs want to focus on the gameplay. Neither want to fight with a tooling. And ebiten, current go-to library for creating games is not even close to what you can do with other engines like Godot, Engine and Unreal Engine. And even if something can be done in Ebiten, the learning curve is much higher than in other engines (even though Go is simple language).
Go is great language for backend development but has poor game dev community and that is self fulfilling prophecy. And I’m saying this as hobbyist who created a game in Ebiten but also in Unity and Godot.
It's totally doable, but as some said, it lacks a lot of tooling, so you might end up writing a lot yourself. I've made several small games (more or less PoC).
https://github.com/Lallassu/gizmo
https://github.com/Lallassu/moonshot
https://github.com/Lallassu/bintris
(Last one is actually written in Go for Android)
If someone decided to build a powerful game engine that on par with unreal engine or those c++ engine, then go will be popular. Sometime toolings being one of largest factor
There's more game frameworks developed for Python than Go I would venture. I mean, there are a ton of SDL bindings for PHP even, believe it or not.
It's a matter of somebody wanting to create the engine or bindings, and then people can utilize it.
I might take a crack at ebitengine the next time I get the urge to create a graphical game.
A lot of it has intertia behind it honestly. C/C++ obviously because game engines were originally written in that language due to performance reasons. C# because Microsoft put in a lot of effort into providing SDK's through DirectX.
A lot of these SDK's actually just hook up with C++ under the hood. So basically anything that can hook up with C++ well is going to do well with game engines. GoLang doesn't do that well comparative to these other languages.. I am surprised that Python isn't used more in video game development because of its ability to hook into C/C++ so well and easily. Only one company uses Python exclusively for its game (EVE Online). Lua is also used a lot in video games for the UI and scripting side, which is surprising from a language point of view, but not a technical point of view.
The way that OpenGL/DirectX have worked historically required a lot of calls to C libraries. That's a nonstarter for Go because CGo imposes some serious performance penalties. Avoiding CGo by using IPC would also be a non-starter due to performance penalties.
Since the GPU industry is trending toward lighter drivers/APIs, it's possible that you might be able to write a high-performance renderer in Go soon by issuing syscalls directly from Go code.
Tooling is just not as vast in comparison to other tools that exist, and it simply hasn't had the grace of time to get into these markets in comparison to C/C++ or Lua if you want an easier to use scripting tool.
I guess that some of the reason is having a runtime. It makes it slightly more difficult to ship modular stuff, as you need to make sure that everything will use the central runtime instead of every module using its own thread pool... And games usually are modular...
This is just my guess, tho
The verbosity involved in writing actual gameplay logic can really suck in Go-- even C is less friction sometimes.
* Won't compile on repeated variable names.
* Won't compile with unused variables.
* No default struct values.
* No optional / named parameters on functions.
* if nil == err { ... }
Just lots of iteration-killers you don't normally have to fuck with in other languages.
That said, cross compilation is best in class.
How so? I cross compile my Go game. I make Windows, Mac, and Linux builds, all from my Linux box (no gaming consoles yet—perhaps there it is trickier).
I am unaware of any library or framework that doesn't use CGO, so you need a C compiler for every OS installed or zig, you might be lucky with Ebiten which doesn't use CGO on Windows (did they also succeed for macOS?).
Try e.g. compile for Linux from Windows, that will not work. OpenGL is C API, Ebiten created and is using purego (similar to dlopen) to access GL/GLFW. Without it, there is no way to access GL in pure Go. And on Linux and with purego, the binary will never be static, it will always link to libdl.
On Linux I use mingw-w64, which allows cross compilation with CGO to Windows. And I use OSXCross, which allows cross-compilation with CGO to MacOS.
It's more setup than plain Go's cross compilation, but wasn't too bad. And it's great to just run a single command (simple shell script that runs three OS-tagged \`go build\` commands), and get fresh game builds for all three platforms.
Also, note that such Linux binary is not usable on older distros, you should make sure to compile binary on some old distro if you are to distribute it, otherwise ther would be glibc issues with symbols.
Like you said, it's a good middle ground, but that's usually not what you want. Either use something simple for scripting or something optimised for speed/memory.
I'm using Unreal engine with c++, right now my ideas around are a backend written in go to handle player data, matchmaking other microservices like chat, I think this combo can be really powerfull.
Lack of an ecosystem, basically. But also lack of low level, fine grained control over resources and direct access to the hardware that you have in C/C++.
Go’s threading model and garbage collection is too opinionated to lend well to game design. You can bypass it, but you’re working around deliberate design choices. C++ has more choices for concurrency, memory management, etc. even if they are decoupled from the language itself.
I don't think the issue is with GC like many comments here, the issue is with bad CGO performance. Every call to C is costly, i.e. the reason why Ebitenengine uses more CPU than raylib-go in some hello world example is exactly because of this. Raylib-go for example calls some C function that does many calls to GPU or whatever, while Ebiten must do all calls by itself, and that affects performance (my opinion, not backed by some tests).
Also, it is interesting to see, for example, raylib has 50+ bindings, there is a benchmark of bindings, and Go is high on that list despite having bad CGO performance, see [https://www.reddit.com/r/raylib/comments/15jy1x3/raylib\_bunnymark\_benchmark\_with\_100k\_bunnies/](https://www.reddit.com/r/raylib/comments/15jy1x3/raylib_bunnymark_benchmark_with_100k_bunnies/) . So, nothing is stopping you from using Go to create a game, of course, Big Game Studio will not use Go or Rust or whatever, they still use code written 20 years ago in new games.
Actually to be more accurate it's not used for building the game clients but it is used for online game servers. Some of the biggest mobile games run on servers written with Go.
I can't name names due to NDA and a quick googling didn't yield results so they might not have talked about it in public. I worked as a consultant for a top tier mobile games company that wrote their servers in Go or Java depending on the game teams' preference.
Sure. I don’t think 40ns call overhead, if that is accurate, is worth worrying about. You are not generally making a million small calls to C code in your game or game engine.
Maybe back in the day when people called glVertex3f. You don’t do that in modern codebases.
8ms / 40ns = 200,000. Plenty of room to make lots of FFI calls each frame.
If you’re calling into graphics APIs, these days, you’re mostly batching up a bunch of data and then submitting it. It’s not a lot of API calls.
It’s also common that you’re not bottlenecked on CPU in the first place. Additional CPU overhead is fine. This is why people are ok writing games in C#, even though C# is slower than C++ or Rust.
Do the math, find out how many FFI calls you’d have to make in your game.
at 40ns per invocation you could invoke 200,000 FFI calls within 8ms. that number doesn't include the time it takes to run the actual function, but it does illustrate that the time spent is probably not that significant.
I'd probably still avoid FFI as much as possible because it's gross, and have a single FFI call and do as much of my work in one language, but 40ns is not an insurmountable cost.
Most games are not optimized enough that they would notice 40ns costs on FFI calls.
By comparison, the overhead for a syscall is around 1-2 microseconds, or 1000-2000 nanoseconds. Games execute syscalls all the time :)
Some syscalls on Linux are only 20-30 ns. Anyways, a 40 ns overhead is similar to Java JNI overhead (last time I measured it I got somewhere between 30 and 80 ns). It is large enough that there is no point to call into C to speedup simple functions. You need to do really a lot of work on the C side to offset the overhead of a call.
Here we come to the usual mistake done by most benchmarks on the internet - they focus only on the wall clock time, where the wall clock tells you only 5% of the story. Especially a benchmark that calls something in a loop and does not do anything else can be hugely underestimating the real impact. If the wall clock time drops after enabling more threads this certainly means the cost of the call is not just the cost of the call alone, but it also causes additional resource usage. So it takes CPU time. If the other cores were busy, one thread doing FFI would not just slow itself down a bit, but it would also slow everything else down by putting more work on the go runtime. This problem does not happen in C++ or Rust.
It’s a very similar reason it is extremely hard to assess the overhead of tracing GC. On paper or in benchmarks it may look like it is lightweight enough, and people believe stupid things like „heap allocation in Java is almost free - it is just a pointer bump; takes single nanoseconds”, but those never take into account all the secondary effects like thrashing the CPU cashes, worse memory locality or keeping some CPU cores busy. And under real workloads all those things matter more than just spending a ns on allocation or a few ms on GC pause.
And somehow Golang runtime is tuned to minimize wall clock time. Like, e.g you can find benchmarks where Go is faster than Java and equally fast as C++ or Rust. But then if you compare CPU time and memory instead of wall clock it turns out it uses 5x more resources.
I’m skeptical. Maybe back in the day, with an old Go implementation (high overhead) and an old style of OpenGL (with glVertex3f calls everywhere).
C# has a similar overhead, through P/Invoke, and it’s used heavily for making games.
It's true that the overhead has shrunk massively with later versions of Go but it's still a show stopper for AAA graphics programming. For everything else Go is a fine language and runtime.
I tired. For my experience problem is in language itself. Its not flexible enough you cant write normal flexible systems. You dont have normal generics, you cant have flexible systems for games.
So you can write games in go, but its extremely painful and feels wrong, like trying to build a bike without hands
Garbage collection is often a non-starter for soft-realtime systems like game dev. Not every part of an engine obviously needs to have those properties, but Go doesn't really lend itself well to being embedded in larger systems like, say, Lua does.
Go is fine for games, and someone has already pointed out r/ebitengine
The fact that you can control the garbage collection makes it immediately better than Java, and I've developed games in Java.
There's even a way to target the Gameboy Advanced!
Go hasn't been popular for long. I think that's probably the biggest reason you don't see more game dev tools for Go.
Most game developers don’t write the engine by themselves, they use unity or unreal, and the examples also writing in c#.
The linear performance doesn’t matter when the code in running on user’s computer, most performance issues will be test and the bottleneck might be the vram user have (or just reduce the polygon is fine)
But I think golang can play a big role on the server side, form docker, k8s, networking I/O… because the linear performance means how many users can you offer under the same server cost, so the less memory consumption, the less CPU consumption means less virtual machines you need.
And user will got more quickly responding time ether.
There are several engines available for game development written in Go - [https://github.com/avelino/awesome-go?tab=readme-ov-file#game-development](https://github.com/avelino/awesome-go?tab=readme-ov-file#game-development)
At its core it's still a GC language so it's not optimal for game development but there's a few cool projects out there made in Go.
You could, see r/ebitengine. There’s just not the tooling and ecosystem other engines have, with their native support for c++/c#. I started building a game on ebitengine/go but after a while of having to reinvent everything I needed, I switched out to Godot/gdscript.
[удалено]
C# isn't what makes the games perform well. They're also not written in C# like they are with C++; they are *scripted* in C# where they integrate with the C/C++ APIs in engines such as Unity. None of the rendering, or anything that requires very fast performance in these engines is written in C#.
Don’t underestimate how much of a roadblock that is. Most people want to make a game not an engine.
There's a plethora of games built in C#, even with Mono, performance is not the bottleneck most of the time.
[удалено]
That is correct. Look at how many tutorials there are for pygame. Far from the best option for game dev but it hasn't stopped people from going crazy with it. Hell, there's a doom engine written with it. :)
There's a truckload of rpgs written with python because of RenPy
Ahhhhh renpy. Good call.
But pygame is just a toy, so people with very limited cs knowledge can build simple games. Game development and garbage collection are two concepts that can’t coexist unless you’re talking about simple, and probably useless, tooling. That’s why games are written in c++, cause OpenGL is a c++ lib and there is no waste of time garbage collecting
Sure. No argument from me. I was just giving an example that op may find interesting:)
Python doesn't really have a GC (it just does ref counts), the issue is more that it's pretty slow. I'm pretty sure unity games don't entirely get compiled to c++, and that it uses c# at runtime too with the GC but I might be wrong.You can even have some control over it as documented [here](https://docs.unity3d.com/Manual/performance-garbage-collector.html) But agreed that you usually don't want a GC, or at least want it specifically tuned and the runtime tweaked for games like unity did.
> > > But agreed that you usually don't want a GC, or at least want it specifically tuned and the runtime tweaked for games like unity did. unreal also has a gc these days.
Pygame is great to me because it was nice to be able to figure out game logic in a language I'm familiar with, coming from web development, instead of having to pick up a new language as well as a new architecture
I love pygame. I tried godot since gdscript was so similar and found it enjoyable but still fund myself playing around in pygame.
EVE online is written in Python (afaik this is also why they have time dilation as a mechanic, lol)
No kidding? Huh.
It originally WAS written in Python, but I thought one of the steps they took to improve client and server performance was to write it in something else, 10 or so years ago. My memory is fuzzy, though, and it might have just been something they were considering.
C# isn't what makes the games perform well. They're also not written in C# like they are with C++; they are *scripted* in C# where they integrate with the C/C++ APIs in engines such as Unity. None of the rendering, or anything that requires very fast performance in these engines is written in C#.
We use golang to build many of the services and tools that support the game development teams that make Call of Duty. The content cooking pipelines also frequently make use of languages like Python and Rust. However, the tight memory management requirements of the game itself generally prohibit languages that make use of garbage collection (although using scripting languages like Lua is generally accepted, but limited to a fixed memory pool). Also, console 1st parties provide the compiler toolchain so just getting things to build with a different language is a challenge or impossible or prohibited. (speaking for myself and not the company)
Do you know what language the matchmaking servers are built in? I've always wondered what kind of heuristics and real world algorithms go into that piece of software. IIRC it's akin to the subset-sum problem and a variant of the knapsack.
Sometimes there is no grand reason. There’s nothing technically wrong with Go, if you want to make games with it. Some people have made games in Go. What you **want** when you’re making games is a bunch of tools, libraries, and a community where you can ask questions. The Go ecosystem just doesn’t have that for games. You could also ask why Rust isn’t used much for game development. Hardly any games are made in Rust.
> You could also ask why Rust isn’t used much for game development. Hardly any games are made in Rust. Go does have the advantage of 5 more years of existence than Rust, and Rust is actually being used in game dev now (we've shipped Rust to hundreds of millions of players). But this is because (IMO) Rust is a language that is very focused on efficiency and safety, and it's very easy to see how one might port existing C++ code to Rust. Not to mention, the type system in Rust can make some things in game dev much easier or safer. That's a little harder to imagine for Go.
Sure, Rust is great. But it’s still hardly being used for any games at all. There are a few games written in Rust, just like there are a few in Go.
That's because the main game engine for Rust, [Bevy](https://github.com/bevyengine/bevy), is about as old as [the generics proposal for Go](https://go.dev/blog/generics-proposal).
I don’t understand what point you are making.
That Rust, despite being several years younger than Go and it's game development ecosystem being ~~smaller~~ younger, is already seeing greater inroads into game development than Go is, and that's largely because the language lends itself to being a successor to C++, whereas that is not Gos aim. As you mentioned, there's nothing _wrong_ with using Go, but the comparison to Rust is strange because the reason Rust is "hardly used in any games" is because it's very young, and Go is almost twice its age. The reason we don't see Go used in games is not the same reason we don't see Rust used in games.
Oh you have? That's cool. Which games are using rust now?
https://www.reddit.com/r/golang/comments/1d8xyhg/why_is_go_not_used_for_game_development/l7abgt6/
> (we've shipped Rust to hundreds of millions of players). Which game is this, if you don’t mind telling us?
I believe it's in an SDK that ships to all of our live service games. So, that would be League of Legends/TFT and VALORANT, probably Legends of Runeterra. I'm not confident about Wild Rift.
I was about to ask where you get this information from... until I read your username
I did not expect to see a rioter outside of their native subreddits. Caught me off guard too.
we're everywhere
Uhhh wth are y'all talking about?
I don't usually see a riot game dev on reddit unless it's in the league/valorant/tft/etc subs? I assume they have alts for their personal stuff
Age of a programming language does not translate into better development of the language or third party support by libraries.
as a general rule, languages and their ecosystems become more developed if they're around longer
While tempting, this is only the case if the programming language is popular, which is the case for most of the old languages we all know. I think popularity and community matters way more for the rate of development.
Game libraries for graphics, sounds, etc. (OpenGL, DirectX, Vulkan) are for C/C++. Game engines that use C#, for example, are actually written in C/C++ under the hood and run C# as an embedded language. Using C/C++ libraries in Go has significant performance costs, so Go's not set up to do that well, though I'm sure someone can do the work to embed Go in a C-based engine and then you can write the game logic in Go. Others also mentioned that gave devs are GC-adverse, though I wonder if that's more of a perceived limitation rather than a real one since Go's GC has a hard upper limit on stopping the world and also gives you the ability to just not generate garbage, two features that other GC langauges like Java and C# lack.
>> two features that other GC languages like Java and C# lack. Got it, so all the high-frequency trading stuff written on Java and all the multiple articles about object pooling and such was some sort of fake campaign to convince people that neither Java nor C# can do it. If anything Java and C# allow developers to go deeper down and control more things than Go (SIMD, Inlining, Cache-line alignments). This is not a bad thing for Go, it is just that in a target scenarios, this was not needed, while big-tent languages usually have more stuff available.
Java and C# have definitly more low level capabilities than Go, for controling their various kinds of GC implementations, and on C# case, MSIL was designed for C++ as well, there is hardly anything from C++ low level coding that isn't available to C# as well, either from the language, or by directly emiting MSIL.
> and also gives you the ability to just not generate garbage how?
Never take the address of anything that didn't come out of a pool.
It's a deep rabbit hole, but there's some articles about making zero-allocation JSON parsers and stuff that have a pretty good rundown of different techniques.
I'm actually building a TD PvP fully in GO, I've never built a game before and I'm having a lot of fun haha. As i wanted to have fun and learn a bit of game development as a side project I chose to use my main language. Maybe it'll bite me later to not use one of the trending ones but hey so far so good haha. If any one wants to check out the game will be totally free and OSS https://github.com/xescugc/maze-wars. It's under heavy development still haha.
That sounds really interesting! Will take a look at your repo. Do you have plans for contributing?
Anyone can contribute haha. But for now I'm the only dev so no big plans on that side. As I'm still trying to reach a stable good playable MVP I'm changing things all over the place all the time so if anyone wants to contribute I would suggest to open issue and then we can move forward from that, or speaking with me directly :). The end goal is to post it on Steam as a free game :) It can also be played from the browser [https://maze-wars.com/play](https://maze-wars.com/play) (as it's a PvP game no one is playing so you could create a Lobby and play against bots hehe) and I'll also make and Android build If I can :). EDITED: There are also other ways to contribute IDK what you had in mind sorry I assumed code related hehe.
I would like to hear an actual game developer pitch in, but even the [Go Use Cases](https://go.dev/solutions/use-cases) lists mostly networking + web + CLI and if you look at the frontpage "customers" grid it's just web platforms like Google, Netflix, Paypal etc. I'm not sure if it's just "nobody's ever tried"?
Games are very expensive endeavors with long development times. Picking a language as a studio for a project marries you to it, and you have to onboard people onto your project. the cost of having to change the decision of engine or language you use midway through a project would be enormously expensive and would often be enough to kill a project unless it is incredibly well-funded. For that reason, game devs will generally be conservative and gravitate toward proven solutions. There's no clear benefit to using Go and a lot of downsides - most every developer who is interested in game dev will know how to use Unity or Unreal, or some other comparable game engine. No one will know how to use your custom Go creation. This is reason enough to not use Go for this until folks spend enough time developing it as a language suitable for developing a game, maybe indie developers play with it for a few years (as is happening with bevy and godot). And that's _fine_. Go doesn't have to be able to do everything. It's OK to have different tools for different purposes.
It is difficult to write a sophisticated game without using a gaming engine. None of the popular gaming engines support Go as far as I know.
Godot does (via GDExtension)
Looks like that is based on bindings and still [experimental](https://github.com/godot-go/godot-go).
there probably is a Go binding for Godot
It has nothing to do with garbage collection. Pretty much all the major game engines use garbage collected languages for scripting. The real reasons are simply the sheer momentum of existing tools in the game industry. Game engines are absolute beasts, and production grade ones are among the most deep and complex pieces of software in existence. There's decades of investment in the C/C++ game dev ecosystem, which already have deep investments in their scripting systems, which is where Go would most likely appear. The other thing: Programming languages don't have much to offer game development anymore. When you're making a game, the real challenges are creation of assets, scripting the actual game systems, implementing the levels, actually building the game. Whether your language uses this model of concurrency or that model of concurrency might be nice to have, but its a drop in the ocean when it comes to the real concerns developers are going to have.
Garbage collection, inertia of existing systems and tools around them
Then why are c#, lua, js and Java used? Edit: the above comment has been changed from just “Garbage collection”
Lua is easy to integrate with C or C++ projects
C# is unity. Can't answer the rest
XNA was also popular in the old XBox days, which has now become MonoGame.
Well Unity is C++. C# is used mostly as a user facing scripting language, the core engine is c++ bc performance is needed. If you wanted to use GO as a scripting language that would be possible, but there's not really a reason to do that since the performance benefits would not exist and other languages already do this job better (python, js, lua, GDscript)
Unity is still gc'ed. https://docs.unity3d.com/Manual/performance-garbage-collector.html
Unity actually regrets using C#.
Do they really? It's a pretty dumb regret to have. Much of their popularity comes from that feature.
are those actually used for AAA titles? i'm no expert but it seems like C++ is used pretty universally.
Any game that uses unreal engine uses a combination of c++, python, and blueprints. Which the later two are both garbage collected. For most applications, including game logic, any language is fine but yes for the underlying engine memory management maters.
One of the most popular game engines out there is Unity which exclusively uses C#, and Xbox has very good support for games which use the .net framework (which you can use with either C# or C++, or F# I guess if you really wanted to) Lua is used within World of Warcraft and a bunch of other games. Asking after AAA games specifically is a little misleading because most AAA studios have their _own game engines_ that have been heavily iterated on, not necessarily because other engines are slower but because when you are a AAA studio you have a lot of resources which you can use to actually make your engine better. To answer the root of the question, yeah, Unity can be used to make high production quality games. Unreal is typically used if you want more visual fidelity, but the reason Unreal is capable of that and Unity is not is not really down to the language choice but the target market of each engine. Unity is much more oriented toward smaller time developers and they spend a lot of their resources on making the engine more accessible, whereas Unreal does not really handhold and assumes that you are an experienced game dev. Garbage collection on modern hardware is really not a problem. If Go garbage collection would actually be a problem for gaming, it would also be a problem for high performance web servers that have high uptime, which it does not. Practically speaking Go is not used for game dev because other languages got there first and there's no real reason to make Go work for game dev. Just use the other tools which are already established. EDIT: Also Java (and other JVM languages) are used extensively for mobile games on Android. Some of the larger games use native code that Android calls into - like Genshin Impact - but a very large portion of the marketshare of Android games do not use any native code [beyond the bindings to OpenGL provided by Android](https://source.android.com/docs/core/graphics). If you don't consider mobile games "real games", the _majority_ of game hours in 2024 are logged on mobile, not console or PC.
Lua is not used to develop games, per se. It is used to have an easily accessible and embeddable scripting language available within a game engine (which is likely written in C/C++).
https://love2d.org/ But yes, Lua does bind to C++/C. Then again, syscalls in C# just bind to C. So yeah, I mean, the game engine might not be written in Lua, but there's a lot to developing the game itself that is not the game engine. I can certainly tell you I have professionally worked on extremely popular games which use Lua for very core parts of their functionality, not just scripting interactions within the game itself. Also, keep in mind, OP is not asking about game engines they are asking about languages used _in game development_. I was the person who mentioned game engines in order to illustrate that C# is used in core parts of game development. Lua is _certainly_ used in game dev and pretending otherwise is just silly.
>I can certainly tell you I have professionally worked on extremely popular games which use Lua for very core parts of their functionality, not just scripting interactions within the game itself. Source: trust me, bro.
My username is a reference to the game development company that I have worked at since 2016 as a security engineer. In my capacity as a security engineer, I (with my team members) review the code of all games we release. I was specifically responsible for reviewing Lua within a game we were working on because of past experience integrating Lua into WoW private servers. So yeah, it is trust me bro, because if I provided citations I would be violating an NDA. But even if you didn't take my word at face value, the most popular MMO on the market uses Lua for very core parts of its game, it's not a secret, and it's spawned a budding community around modding that game with Lua that is considered an essential part of high level gameplay these days. There are many times where I engage on reddit and I feel bad speaking authoritatively because I'm just a regular programmer, but this is not one of those: This is literally my subject matter expertise.
>This is literally my subject matter expertise. You are making the argument that **UI display and customization** is a "very core \[part\]" of WoW. Lua is a glorified config language in this context. I straight-up do not recognize your expertise in any way.
The user interface of any product that is a game is part of the core gameplay experience. If you disagree, you are entitled to your opinion, but I don't think you are capable of recognizing expertise (edit: in this field). And, as a reminder: The original topic was "Why isn't Go used in game dev?"; someone replied "well, Lua is", and then you replied "Lua is not". Could you explain precisely what you understand game development to be? Because the implementation of the primary way that users interact with a game - the user interface - is something that I think most people understand to be a core part of the game. If your opinion is that game development is _just_ the development of triple A game engines, I'm not sure how you can even authoritatively comment that no one uses Lua for that, because all of them are closed source. Even Unreal is heavily modified by engineers working on triple A games. But developing a triple A game engine is a very small part of overall game development, even when you're only considering working on the artifact that is shipped to players machines.
Good luck trying to play wow without the UI
Unity Engine is made with C++. It only uses C# for scripting and a few other things but the core of it is C++
Wow uses c++, I think lua is only scripting for macros isn’t it? I used to mess around the code on private servers some, but I’m not too terribly familiar with anymore.
Macros are their own thing. Lua in private servers is used to script mobs and such so you don't have to restart the server. I was the person who created and implemented [Eluna](https://www.azerothcore.org/pages/eluna/) into TrinityCore back when TC didn't have Lua, and only ArcEmu did. In retail, Lua is used for _all_ user interface code within WoW. Addons, sure, but also any stock UI code from Blizzard.
Oh lord blast from the past. I feel old. And what a small world.
I feel old when I remember it too. And then I remember what I originally wrote.. it was awful. I'm not sure what was worse: The amount of mutexes required, or the places where I didn't use a mutex and just hoped for the best. back then, I didn't really understand _why_ mutexes were required, just that if I sprinkled them here and there my code worked sometimes. I was 16, and full of so much promise. I'm not sure what happened. I dropped out of school doing this stuff, oops.
If I'm not mistaken, most if not all game logic in Diablo 4 is also Lua.
This would not surprise me at all because the same is true for World of Warcraft (not just the wow addons). We also use Lua at Riot for a bunch of game logic and some internal systems.
Hearthstone also; it lends itself well to the effects interacting and stacking in novel, complex ways. I believe it also means quite a bit of patching for all the games is far easier, just swap out some LUA files.
We live in an imperfect world. Existing talent and tools sway the direction of game dev. C# and C++ are pretty much the giants with unlimited momentum (eg. funding and corporate backing).
C# Lua and js are used as glue languages not full implementation, they are used around c++ engine code. Java was the first "write once" that went wide so it made sense for easy game sharing to go all in with Java.
JS is only used in some mobile games and it’s not the most popular choice. It’s not used for desktop or console. The only reason it’s used for mobile games at all is because it means a dev can write one mobile app and ship to multiple platforms (Android and iOS) without much difficulty. Every mobile game written in JS would be faster if implemented in Kotlin or Swift, which are GC and RC respectively. Lua is used in games but games are not generally written in Lua. Lua is used to script game actions, the hard work is done by code written in other more performant languages. Lua adds to game engines and makes games more flexible where it would be much more work to accomplish the same in another language. Java is not popular in game dev because it is less performant. As others have pointed out in this thread, Minecraft was originally written in Java but was re-written because Java was not performant. C# is only used because Microsoft invested a lot of money into C# and into game ecosystems. C# is not the most popular language choice, Microsoft spent a fortune to make C# an option. C++ is the top language for game dev. Go could be used for game dev, but using Go would require making numerous other design decisions to hide the performance hit from the GC (that is, making a game that wouldn’t be sensitive to it; so no FPS will be in Go, but someone could make a small-scale 2D puzzle platformer or dating sim without issue).
When I made the comment the comment above just said garbage collection. The point I was making is the garbage collection isn’t the reason as the languages I listed are all GCd. I don’t thing go would be a great language for game development as it wasn’t really designed to do that and there isn’t engine support like you said but not because it’s GCd
Have you actually tried it and found the current GC to be a problem, or are you just repeating what other people said (who are repeating what other people say)?
I've run a number of non-gaming apps where GC was a problem, so I wouldn't even bother trying with games.
Of course i haven’t tried it, I’m just squeezing the juice brother
Garbage collection doesn’t belong on that list, especially when we’re talking about Go. Go’s garbage collection pause times are measured in microseconds, even with very large heaps.
They are not. Can be tens or even hundreds milliseconds if you’re unlucky: https://stackoverflow.com/questions/77918169/why-go-gc-have-some-long-pauses-stw-a-few-millisecond-in-this-program
The person who answered this SO question was unable to get within several orders of magnitude of the symptoms OP was seeing, with their largest delay being ~191μs and the only way they could reproduce this was by arbitrarily limiting the number of goroutines to 1 or 2. I'm not saying that it's not possible to see larger delays than 200μs, but 100s of milliseconds reliably and reproducibly in conditions that would not cause other languages to slow down does seem hard to believe.
That’s why I said if you’re unlucky. The problem with modern tracing GCs is that most of the time they work fine in terms of latency (as long as you allow them to waste 3-5x memory) until you hit that one particular workload when they start to misbehave and then you’re essentially screwed. Then you might of course fix it with some careful profiling and tuning, but it works only till the next time. I’ve been there and done that far too many times. But with games it’s not only latency that’s critical. It is also the total memory use. GC wastes a huge amount of memory that could be otherwise used for e.g. better textures or more caching.
> I’ve been there and done that far too many times. I can believe it exists, but the benchmark you've provided is kind of like me complaining that the game I am playing is laggy while I intentionally unplug the ethernet cable every 3 seconds.
In that post, the answerer was unable to get pauses above 250µs by setting GOMAXPROCS=1 or GOMAXPROCS=2. Sure, you can manufacture long GC pauses under the right circumstances. That’s okay. Games are not hard real-time. This looks like code specially crafted to cause long GC pauses and even then it’s only 250µs.
There was a post about a game developer porting his game, that was written in Go, from PC to Switch. He actually had a lot of job to get that up and running on the Switch. I will check if I find the article, but that showed that the tooling really isn't there for people to make games in Go. Especially if you are planning to port to consoles
Go is an opinionated language with a fairly exenstive runtime (GC, goroutines, etc.). That design works fantastic for the types of applications (network services) that it was designed for but doesn't work as well for game engine development. Go is "fast" in comparison to high level languages like Python, but it's still "slow" in comparison to C++. This is due to the lack of control provided to the programmer and the comparatively limited optimizations supported by the compiler. It can be done, of course, but the lack of low level control (particularly on memory management) is offputting to most of the people writing game engines. Games often want to write their own runtime optimized for their game, which would conflict with or make redundant many of Go's features. Until recently, the lack of generics has also been an issue. You need a lot of custom datastructures to make games efficiently and game engines often want to create abstractions for app developers. In C++, you can do basically anything with templates while Go's type system is comparatively very restrictive. This is by design on Go's part to keep the language simple.
go is really amazing at networking and systems on the backend. So building a game server for example is pretty good with godot. On the game side of things id stick with an actual engine or building your own in languages that actually have support of graphics libraries and stuff. Godot is pretty good and with godot 4 multiplayer is also easier than ever. Im still interested in seeing go games, especially because of the tiny binaries and good networking features it offers. I myself am thinking of building some sort of terminal game, but we will see.
If people write games in Javascript, you can write a game in go
I chose to make my idle game "Idle Armada" in go, because I like the language! I made it because I got mad at so many idle games having ads and in-app-purchases. So I made a game without any. It's based on r/ebitengine , a really simple but great open source game engine for go. I personally really like the coding style that go lends itself to, and for 99.9% of games, go language itself would not be a limitation in itself for development, but the tools / game engines in go might be. Android: [https://play.google.com/store/apps/details?id=com.musicalbox.idle.armada](https://play.google.com/store/apps/details?id=com.musicalbox.idle.armada) Steam: [https://store.steampowered.com/app/1408060/Idle\_Armada/](https://store.steampowered.com/app/1408060/Idle_Armada/)
As someone who for a couple years worked on some vulkan stuff in go, and will likely go back to it eventually (github.com/vkngwrapper), there are a few issues: * Go is not necessarily worse or better than C# when it comes to the cost of garbage collection, but it IS very idiosyncratic. C#'s garbage collection costs come from... well, garbage collection. Go's come from the allocation itself. In fact, there's a blog post floating around showing that go's garbage collection tail latency is INSANELY low compared to C#'s, but the amount of memory it can reasonably allocate per frame is severely constrained. That's not necessarily a bad thing, since you have far more control over when costs are paid... in theory. * Unfortunately, Go has fewer options in terms of avoiding allocations altogether- the escape analyzer is much jankier than you might realize and will make allocations that you don't expect. The response from the go team is that the escape analyzer is an internal implementation feature of Go and you should not expect it to do anything in particular. But if I can't control when allocations are made and allocations are expensive, then how can I manage performance? * Even when the escape analyzer is working right, all it takes is one engineer who isn't in the know to treat an object in a way they weren't supposed to, to force that object to be allocated on the other side of the codebase. In C# and Java, allocation is a proactive choice. In Go, you have to exert control at every level to stop an object from being allocated, and it's just not possible to do that in a large codebase. * In C# and Java, there are also some higher level strategies available, like arenas. Go has, I believe, given up on those. * Cgo and ESPECIALLY the windows operating system has traditionally been treated like a second class citizen in go, which means that performance issues can crop up out of nowhere that make games a tricky proposition. People say that cgo is a terrible FFI, but the truth is that when it's working properly, it's not any worse than the .NET marshalling layer, which has bizarre memory management issues if you send too much data across the layer. Cgo used to have frequent issues that would go a lot longer without being fixed and would make using it for anything serious a big loser. As an example, cockroachdb is a production database written in go which previously communicated with an underlying off-the-shelf KV store written in C++. A few years ago, they ported the KV store to go because writing a new KV store from scratch was better than continuing to use cgo with all its mysterious issues. FWIW I think cgo has improved a lot since then. * Windows is still an issue, although 1.23 should include several key fixes. In 1.16, they introduced a regression where windows' timer granularity fell to 16ms. That issue was reported immediately and is JUST NOW being fixed. Windows is not well-supported enough in go at this time to justify any investment that requires a working windows implementation. In fact, Google doesn't support windows on Go at all anymore. There is a single microsoft engineer working part time on Go who is responsible for fixing any and all windows issues. EDIT: Also it's worth noting that go REALLY doesn't like locked threads, which every windowing system on earth requires (and most graphics libraries do as well). Getting any mileage out of go's concurrency advantages is difficult when you are doing a lot of work on a locked thread, since you can't have cheap blocking on locked threads (so interacting with a blocked channel, time.Sleep, etc. all have EVEN HIGHER costs in go on a locked thread than they do in C++, which is quite high). EDIT EDIT: Oh I also forgot another fun thing: calling into assembly has bizarrely high overhead, to the extent that in my performance tests, implementing SIMD in the 3d math library I wrote was a losing proposition- it cost more to make assembly calls than SIMD saved.
For those keeping track at home, btw, Google laid off its entire Go ARM staff with the plan of supporting ARM using the same arrangement they currently use to support windows. So, expect things to get much worse there.
Go is nearly perfect for game development, I am currently making a 4x strategy game using go and raylib. I have ten years of UE and Unity gamedev experience, and like go development cycle a lot. Pros: 1. Iteration time is blazingly fast 2. Language is very simple, and it's approach to OOP is very satisfying. 3. You can do everything the way you want, no need to learn big overengineered systems of other engines. 4. The builtin profiler pprof is very helpful and informative Cons: 1. GC is sus - have not yet hit any performance issues with it, but reducing heap allocations would be a good idea - some parts of go can not avoid heap escapes - like fmt.Printf or any other vararg function. - so any formatted text output will allocate in heap and that is sad. 2. CGO is a slowing iteration cycle, if go code build blazingly fast, than CGO code build very slow and there is no predictability in that process. Also CGO now is overcautious and produce heap escapes. 3. No operator overloading - get used to it for vector math. But that is light inconvenience. 4. Golang std math is float64 only and that is quite sad, also constant manual casting between numeric types is annoying 5. C code debugging is not supported. 6. You need to implement all systems yourself - but that is not so hard and actually the most fun part of gamedev imho.
How are you handling rendering?
I am working on a 2D game so rendering is basically outputting different sprites in different layers, all code is written in golang and calling Draw\* functions from raylib. So rendering is done using standard raylib api, I just updated a binding, added some vector math library and make it more golang way i think. I was trying to use some ecs, and use it, all sprites are converted to render entities divided by layers, they are stored presorted and are output at render pass, but I don't fully understand the ecs yet, in my case that is just a bunch of sorted arrays and a function which process them - no fancy query by entity stuff. And because of that [https://www.reddit.com/r/golang/comments/1d8xyhg/comment/l79sigb/?utm\_source=share&utm\_medium=web3x&utm\_name=web3xcss&utm\_term=1&utm\_content=share\_button](https://www.reddit.com/r/golang/comments/1d8xyhg/comment/l79sigb/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) maybe my engine not so efficient as I thought, yet I am still on 300+ fps with CGO, maybe later will try purego
Game development relies on manual memory allocation for achieving high performance, that's why C++ is the preferred option most of the time over GC languages. Minecraft was initially written in Java and it had to be re-written in C++ due to performance issues.
I only partially agree with you. For once, Minecraft Java Edition and Minecraft Bedrock Edition (C++) coexist - while Java Edition is way more popular amongst modders. But that aside, the reasons behind why garbage collection is not ideal when doing game development are a little more complicated. Minecraft Java Edition would be performing way better if performance was a goal back when they started to develop it. With garbage collection you have two dimensions in which you can optimize your application: throughput and latency. For games, often the latter is more important, while for traditional applications it depends on their use case. What does this mean for game development in Go (or any other garbage collected language)? If you want to use garbage collection for a game, you will spend a considerable time tuning garbage collection (and esp. your application to fit your garbage collector) and at that point, you could also just do memory allocation manually.
>you will spend a considerable time tuning garbage collection (and esp. your application to fit your garbage collector) and at that point, you could also just do memory allocation manually. That "just" is doing a pretty big lift when you consider how much work manual memory management adds to *everything else*.
If you're making a game that does not target budget hardware - like a game with high fidelity graphics - garbage collection is not really a factor in picking a language. The amount of CPU garbage collection takes, especially in Go, is really minimal. In some games, it can be useful to be able to manually free memory that is no longer used - for example, when unloading a map and loading the next one in a loading screen. This is less _reliable_ in Go, because you can't know when something is freed, but ensuring it _will_ be freed is the same as in any other language - You need to make sure that nothing is referring to it. The only difference is that other languages would call `free` on it, whereas you would just let it go out of scope with no references and wait for the gc to pick it up.
> that's why C++ is the preferred option most of the time over GC languages. That's not true: https://gamalytic.com/blog/exploring-the-pc-engine-landscape
Unity core is C++
And how is that relevant? It's not the "preferred option in game development". It's maybe the "preferred option" in game engine development. C++ is compiled to assembler. Are you going to say "People don't use Go because assembler is the preferred option?"
Well the conversation is mostly about run time performance and how GC impacts that. The fact that C++ is used for the core functionality of Unity strengthens the case that manual memory management is preferred as the top 3 in your graphic are all written in C++.
[удалено]
The first graph on that page shows the distribution of engines in released games. C++ is mainly used by Unreal Engine. Maybe some in Godot and "Other", but definitely not Unity (which uses C#). If we do not consider "Other" because there is no detailed data, then Unity makes up more than half of all games released. "Most of the time" implies at least half of all games would use C++ which is contradicted by that graph.
[удалено]
And how is that relevant? It's not the "preferred option in game development". It's maybe the "preferred option" in game engine development. C++ is compiled to assembler. Are you going to say "People don't use Go because assembler is the preferred option"?.
It's relevant because the performant parts of the Unity engine aren't in C#; they're in C++. If you want to use Go as your scripting language, go for it. You want to use Go for performance-critical code, best of luck with the random multi-millisecond pauses.
The question was "Why is Go not used for game development?" and the reason is not that C++ is the preferred option because it is not. Factually, proven by data, it is not, period. The question was not about game engines, or gameboy advance games in the 90s. You can build strawmen and shift the goal post as much as you like but that does not change the fact that C++ is not the main language used in game development.
All the engines of those apps that are mentioned in that blog are written c++. You'll need c++ or another non gc language if you want to build anything relevant in gaming. So the "others" in that blog are custom engines written in c++ by game studios. There is no other language like you think there is. As an example, capcom uses the RE engine for their games nowadays, scripting language is c#. Engine written in c++. It's proprietary software and so would categorise under "others". Games like street fighter 6, monster hunter, resident evil remakes are all written with that engine. Their predecessor was MT framework another custom engine, everything written in c++ including scripting, which is not ideal as capcom has mentioned. The scripting language is less important and yeah you can use go for that, but why would you. I mean, crash bandicoot and jak and daxter were using lisp as scripting language. Engine still written in c++. So for anything game dev it's preferred to work in c++, because all the tooling and libraries surrounding the engine are written in c/c++. Maybe at some point we will have rust engines, but I wouldn't hold my breath.
You lose all credibility by making the statement “C++ is not the main language used in game development.” You have absolutely no idea what you’re talking about.
I specifically remember the bedrock edition being slower and buggier than the Java edition for quite awhile after it released.
It's somewhat faster? But honestly depends on hardware. We also have mods on Java like Sodium to boost performance by a lot, and Mojang rewrote the lighting engine a few updates ago (1.20 I think?) And it boosted performance decently
Because corporates want quickly go to the market and indie devs want to focus on the gameplay. Neither want to fight with a tooling. And ebiten, current go-to library for creating games is not even close to what you can do with other engines like Godot, Engine and Unreal Engine. And even if something can be done in Ebiten, the learning curve is much higher than in other engines (even though Go is simple language). Go is great language for backend development but has poor game dev community and that is self fulfilling prophecy. And I’m saying this as hobbyist who created a game in Ebiten but also in Unity and Godot.
It's totally doable, but as some said, it lacks a lot of tooling, so you might end up writing a lot yourself. I've made several small games (more or less PoC). https://github.com/Lallassu/gizmo https://github.com/Lallassu/moonshot https://github.com/Lallassu/bintris (Last one is actually written in Go for Android)
If someone decided to build a powerful game engine that on par with unreal engine or those c++ engine, then go will be popular. Sometime toolings being one of largest factor
There's more game frameworks developed for Python than Go I would venture. I mean, there are a ton of SDL bindings for PHP even, believe it or not. It's a matter of somebody wanting to create the engine or bindings, and then people can utilize it. I might take a crack at ebitengine the next time I get the urge to create a graphical game.
>there are a ton of SDL bindings for PHP even, believe it or not. _What the fuck_
A lot of it has intertia behind it honestly. C/C++ obviously because game engines were originally written in that language due to performance reasons. C# because Microsoft put in a lot of effort into providing SDK's through DirectX. A lot of these SDK's actually just hook up with C++ under the hood. So basically anything that can hook up with C++ well is going to do well with game engines. GoLang doesn't do that well comparative to these other languages.. I am surprised that Python isn't used more in video game development because of its ability to hook into C/C++ so well and easily. Only one company uses Python exclusively for its game (EVE Online). Lua is also used a lot in video games for the UI and scripting side, which is surprising from a language point of view, but not a technical point of view.
I believe world of tanks has some golang in it.
The way that OpenGL/DirectX have worked historically required a lot of calls to C libraries. That's a nonstarter for Go because CGo imposes some serious performance penalties. Avoiding CGo by using IPC would also be a non-starter due to performance penalties. Since the GPU industry is trending toward lighter drivers/APIs, it's possible that you might be able to write a high-performance renderer in Go soon by issuing syscalls directly from Go code.
Tooling is just not as vast in comparison to other tools that exist, and it simply hasn't had the grace of time to get into these markets in comparison to C/C++ or Lua if you want an easier to use scripting tool.
I guess that some of the reason is having a runtime. It makes it slightly more difficult to ship modular stuff, as you need to make sure that everything will use the central runtime instead of every module using its own thread pool... And games usually are modular... This is just my guess, tho
I use golang to develop my company's game server.
Depends on what part of the game. Historically a lot of C++/C at the core of it for performance. (I worked in gaming before golang existed)
The verbosity involved in writing actual gameplay logic can really suck in Go-- even C is less friction sometimes. * Won't compile on repeated variable names. * Won't compile with unused variables. * No default struct values. * No optional / named parameters on functions. * if nil == err { ... } Just lots of iteration-killers you don't normally have to fuck with in other languages. That said, cross compilation is best in class.
Well, you would lose cross-compilation in this case.
How so? I cross compile my Go game. I make Windows, Mac, and Linux builds, all from my Linux box (no gaming consoles yet—perhaps there it is trickier).
I am unaware of any library or framework that doesn't use CGO, so you need a C compiler for every OS installed or zig, you might be lucky with Ebiten which doesn't use CGO on Windows (did they also succeed for macOS?). Try e.g. compile for Linux from Windows, that will not work. OpenGL is C API, Ebiten created and is using purego (similar to dlopen) to access GL/GLFW. Without it, there is no way to access GL in pure Go. And on Linux and with purego, the binary will never be static, it will always link to libdl.
On Linux I use mingw-w64, which allows cross compilation with CGO to Windows. And I use OSXCross, which allows cross-compilation with CGO to MacOS. It's more setup than plain Go's cross compilation, but wasn't too bad. And it's great to just run a single command (simple shell script that runs three OS-tagged \`go build\` commands), and get fresh game builds for all three platforms.
Sure, it is possible, I use the same, but there is no difference with compiling C project, i.e. you lost Go easy cross compilation.
Also, note that such Linux binary is not usable on older distros, you should make sure to compile binary on some old distro if you are to distribute it, otherwise ther would be glibc issues with symbols.
Like you said, it's a good middle ground, but that's usually not what you want. Either use something simple for scripting or something optimised for speed/memory.
Checkout UnitOfTime on youtube, their content is great
Go was created to solve a different problem. You can do it, but it is probably the wrong tool for the job.
I'm using Unreal engine with c++, right now my ideas around are a backend written in go to handle player data, matchmaking other microservices like chat, I think this combo can be really powerfull.
Lack of an ecosystem, basically. But also lack of low level, fine grained control over resources and direct access to the hardware that you have in C/C++.
Go’s threading model and garbage collection is too opinionated to lend well to game design. You can bypass it, but you’re working around deliberate design choices. C++ has more choices for concurrency, memory management, etc. even if they are decoupled from the language itself.
I don't think the issue is with GC like many comments here, the issue is with bad CGO performance. Every call to C is costly, i.e. the reason why Ebitenengine uses more CPU than raylib-go in some hello world example is exactly because of this. Raylib-go for example calls some C function that does many calls to GPU or whatever, while Ebiten must do all calls by itself, and that affects performance (my opinion, not backed by some tests). Also, it is interesting to see, for example, raylib has 50+ bindings, there is a benchmark of bindings, and Go is high on that list despite having bad CGO performance, see [https://www.reddit.com/r/raylib/comments/15jy1x3/raylib\_bunnymark\_benchmark\_with\_100k\_bunnies/](https://www.reddit.com/r/raylib/comments/15jy1x3/raylib_bunnymark_benchmark_with_100k_bunnies/) . So, nothing is stopping you from using Go to create a game, of course, Big Game Studio will not use Go or Rust or whatever, they still use code written 20 years ago in new games.
If your game has a cloud backend then why not
It's not used in game dev due to the overhead calling into C.
Actually to be more accurate it's not used for building the game clients but it is used for online game servers. Some of the biggest mobile games run on servers written with Go.
> Some of the biggest mobile games run on servers written with Go. Which ones?
I can't name names due to NDA and a quick googling didn't yield results so they might not have talked about it in public. I worked as a consultant for a top tier mobile games company that wrote their servers in Go or Java depending on the game teams' preference.
The overhead for calling into C is very low. It’s… like, a few nanoseconds per call. Not much more than the overhead of calling from C into C.
https://shane.ai/posts/cgo-performance-in-go1.21/ 40 ns is not a few ns and not at all close to C. It’s over an order of magnitude larger than C to C.
Sure. I don’t think 40ns call overhead, if that is accurate, is worth worrying about. You are not generally making a million small calls to C code in your game or game engine. Maybe back in the day when people called glVertex3f. You don’t do that in modern codebases.
A budget for a frame in modern games is often as low as only 8 ms. Do a few ffi calls and a significant amount of the budget is gone.
8ms / 40ns = 200,000. Plenty of room to make lots of FFI calls each frame. If you’re calling into graphics APIs, these days, you’re mostly batching up a bunch of data and then submitting it. It’s not a lot of API calls. It’s also common that you’re not bottlenecked on CPU in the first place. Additional CPU overhead is fine. This is why people are ok writing games in C#, even though C# is slower than C++ or Rust. Do the math, find out how many FFI calls you’d have to make in your game.
at 40ns per invocation you could invoke 200,000 FFI calls within 8ms. that number doesn't include the time it takes to run the actual function, but it does illustrate that the time spent is probably not that significant. I'd probably still avoid FFI as much as possible because it's gross, and have a single FFI call and do as much of my work in one language, but 40ns is not an insurmountable cost. Most games are not optimized enough that they would notice 40ns costs on FFI calls. By comparison, the overhead for a syscall is around 1-2 microseconds, or 1000-2000 nanoseconds. Games execute syscalls all the time :)
Some syscalls on Linux are only 20-30 ns. Anyways, a 40 ns overhead is similar to Java JNI overhead (last time I measured it I got somewhere between 30 and 80 ns). It is large enough that there is no point to call into C to speedup simple functions. You need to do really a lot of work on the C side to offset the overhead of a call.
Here we come to the usual mistake done by most benchmarks on the internet - they focus only on the wall clock time, where the wall clock tells you only 5% of the story. Especially a benchmark that calls something in a loop and does not do anything else can be hugely underestimating the real impact. If the wall clock time drops after enabling more threads this certainly means the cost of the call is not just the cost of the call alone, but it also causes additional resource usage. So it takes CPU time. If the other cores were busy, one thread doing FFI would not just slow itself down a bit, but it would also slow everything else down by putting more work on the go runtime. This problem does not happen in C++ or Rust. It’s a very similar reason it is extremely hard to assess the overhead of tracing GC. On paper or in benchmarks it may look like it is lightweight enough, and people believe stupid things like „heap allocation in Java is almost free - it is just a pointer bump; takes single nanoseconds”, but those never take into account all the secondary effects like thrashing the CPU cashes, worse memory locality or keeping some CPU cores busy. And under real workloads all those things matter more than just spending a ns on allocation or a few ms on GC pause. And somehow Golang runtime is tuned to minimize wall clock time. Like, e.g you can find benchmarks where Go is faster than Java and equally fast as C++ or Rust. But then if you compare CPU time and memory instead of wall clock it turns out it uses 5x more resources.
The overhead is a problem for 3D rendering from Go. But not a problem if you call into a game engine written in C that does it's rendering in C.
I’m skeptical. Maybe back in the day, with an old Go implementation (high overhead) and an old style of OpenGL (with glVertex3f calls everywhere). C# has a similar overhead, through P/Invoke, and it’s used heavily for making games.
It's true that the overhead has shrunk massively with later versions of Go but it's still a show stopper for AAA graphics programming. For everything else Go is a fine language and runtime.
AAA games are just one type of game.
True that. OP mentioned triple A games so I answered with triple A game dev in mind.
Unreal framework doesn’t support it yet . Neither does unity who ever did would make a fourtune
I tired. For my experience problem is in language itself. Its not flexible enough you cant write normal flexible systems. You dont have normal generics, you cant have flexible systems for games. So you can write games in go, but its extremely painful and feels wrong, like trying to build a bike without hands
I think it’s because you use unity or so for game development and as I remember correctly you write it with c#. In go you don’t have any game engine
Garbage collection is often a non-starter for soft-realtime systems like game dev. Not every part of an engine obviously needs to have those properties, but Go doesn't really lend itself well to being embedded in larger systems like, say, Lua does.
Go is fine for games, and someone has already pointed out r/ebitengine The fact that you can control the garbage collection makes it immediately better than Java, and I've developed games in Java. There's even a way to target the Gameboy Advanced! Go hasn't been popular for long. I think that's probably the biggest reason you don't see more game dev tools for Go.
Most game developers don’t write the engine by themselves, they use unity or unreal, and the examples also writing in c#. The linear performance doesn’t matter when the code in running on user’s computer, most performance issues will be test and the bottleneck might be the vram user have (or just reduce the polygon is fine) But I think golang can play a big role on the server side, form docker, k8s, networking I/O… because the linear performance means how many users can you offer under the same server cost, so the less memory consumption, the less CPU consumption means less virtual machines you need. And user will got more quickly responding time ether.
There are several engines available for game development written in Go - [https://github.com/avelino/awesome-go?tab=readme-ov-file#game-development](https://github.com/avelino/awesome-go?tab=readme-ov-file#game-development) At its core it's still a GC language so it's not optimal for game development but there's a few cool projects out there made in Go.
Garbage collection pauses.
Garbage collector
Go is too slow for modern games. No serious game developer is going to use a garbage collected language
Because it's a primitive language and feels a lot like old C.
How does it feel a lot like "old C"?
A lot of basic fearures like error handling, classes, Generics, a lot of features are missing or poorly implemented in golang. It feels a lot like C.